Re: [GTALUG] why I like shared libraries -- no longer a popular position

2023-09-23 Thread Dhaval Giani via talk
>
> The linux kernel requires that code contributors be registered.  I
> think that contibutions must be cryptographically signed, but I'm not
> sure.  This helps but isn't air-tight.
>

This is news to me.  No, there is no registration to work on the kernel.
There us no single authority who you could register with. I believe i know
what your misunderstanding is. after the 2012 breach, Linus prefers your
tags be signed (i recall there are still a few straggler maintainers out
there). This doesn’t affect the average contributor because they don’t send
pull requests to Linus. Now because we wanted signed tags and key
distribution is a fun problem, one needed to get their keys signed. The
protocol was - I know this person and have verified their identity, so i
will sign their key. One of the things we did was check each others
government issued ids. Of course we are no experts in spotting fake ids so
that is a risk factor considered. But for most part we signed each others
keys and “verified” their identity and I think you misremembered it as
registering.

Dhaval

>
> I don't see that static linking would help with this problem.
> ---
> Post to this mailing list talk@gtalug.org
> Unsubscribe from this mailing list
> https://gtalug.org/mailman/listinfo/talk
>
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] brands matter; Lenovo's brands

2023-09-18 Thread Dhaval Giani via talk
On Mon, Sep 18, 2023 at 7:16 PM Evan Leibovitch via talk 
wrote:

> The more this thread continues the more I am reminded about the role of
> inertia in branding and marketing.
>
> Gaining a new customer (ie, getting them to switch brands) is a lot harder
> than keeping existing ones, especially in mature markets. It's why many big
> scummy companies treat you like dirt until the moment you threaten to
> switch, at which point they shunt you to "retention" departments that
> sometimes offer the only situations one could call competitive. Maybe.
>
> I'd say that now HP,  Dell
> 
> and Lenovo
>  all
> expend the minimum necessary effort to support Linux, though that support
> takes different forms. All know that you can't sell servers that won't
> support Linux, and we don't have the compatibility issues of the early days
> (where support meant not just PC markers but those of add-on interfaces
> such as Adaptec and Digitech). Now most compatibility issues are either
> BIOS related (mostly solved, and the fault of Microsoft rather than
> hardware makers) graphics card and USB dongles (not an issue for servers
> and not actually the fault of the laptop makers).
>
> The "Thinkpad love" I see here IMO appears to reflect the age and
> experiences of the discussion participants. Early in the days of PCs there
> was way more diversity in hardware that could be explicitly Linux friendly
> or hostile, and IBM was friendlier from the start when not all were.
> Recall that in the 90s and 00s, HP, IBM and Dell (well DEC which was
> eventually consumed by Dell via Compaq) all had big legacy
> Unix/minicomputer businesses to protect, plus under Ballmer Microsoft was
> overtly and aggressively hostile. IBM probably did the best job in not
> letting all this get in the way of providing Linux support early on its
> high-end PCs, and that reputation has stuck to the Thinkpad brand to this
> day.
>
> It would be interesting to see how anyone here who has only started buying
> computers in the last 15 years or so regards this reverence for Lenovo.
>
>
I think I bought my first laptop in 2011 (so I guess that puts me in this
category :-)). I have always had Linux on my computers, to the extent of
not signing on with an employer when they needed me to run only Windows. I
have owned thinkpads, HPs, and had experience on a couple of other brands
(netbooks and MSI). Thinkpads have generally have had the best support for
Linux - and not because Lenovo cares, but simply because majority of the
developers I know of preferred using thinkpads. Having said that - I have
had really positive experience with Lenovo support. HP wouldn't care what I
had on the laptop and reimaged Windows on it. Not to mention trying to
setup Linux on it was a nightmare (and I think I fit the category of
advanced Linux users). In another case (I think it was an MSI), I knew the
hardware was supported by Linux, but I could only get everything working
with Fedora rawhide. Coming back to thinkpad support though - I have rarely
had issues with them supporting hardware irrespective of the OS running on
it. It was easier of course if it had Windows, but they would send out a
technician who had their own boot disk to boot into their diagnostic OS and
confirm the issue (I did pony up the extra $s for the in person support).
My employer also has kernel developers working with Lenovo for some of
their laptops to ensure that Linux support is in, which has resulted in a
number of fixes to bioses and to the kernel. I believe we do it with a few
other OEMs, but Lenovo was the one I cared to find out about since I have a
thinkpad.

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Landline and Bell revisited.

2023-09-07 Thread Dhaval Giani via talk
On Thu, Sep 7, 2023 at 10:27 AM Evan Leibovitch  wrote:

> On Thu, Sep 7, 2023 at 12:50 PM Dhaval Giani 
> wrote:
>
>>
>> On Thu, Sep 7, 2023 at 9:36 AM Evan Leibovitch via talk 
>> wrote:
>>
>>> On Thu, Sep 7, 2023 at 11:40 AM James Knott via talk 
>>> wrote:
>>>
>>>
 > Bell faces human rights complaint over allegations of inaccessibility for
 blind customers
 > https://globalnews.ca/news/9373449/bell-human-rights-complaint/

 This is about what Bell is not providing, even though other companies
 do. However, this is current technology, not obsolete, which Karen seems
 to need.

>>>
>>> I call shenanigans on that perspective.
>>>
>>> Given the nature of our group it is natural that some here will see the
>>> issue as merely one of choice and pace of technology, but IMO it must be
>>> seen as a broader issue of problem-solving.
>>>
>>
>> Evan, I did not read James' response in that vein. I read it as genuine
>> curiosity.
>>
>
> Forgive me for insisting that technical curiosity take a back seat to the
> real-world medical needs of people. But I will insist. This is a real
> problem, not an experiment nor a business decision.
>
>

Then this is not the right venue to have this discussion. We cannot fix a
"Bell needs to fix this" issue on this mailing list. Regardless, it does
not excuse the name calling.



> Keep in mind that this group is primarily engineers/problem solvers.
>>
>
> So far the engineering-based problem-solving I've witnessed in this thread
> has amounted to "you can't get there from here". Explaining how Bell's
> system works now does zero to solve Karen's technical issues, let alone the
> quality of the customer-service response to her actions to date.
>

No, a lot of the questioning has been about - this is what is happening. So
where is the gap?


>
> And I think it is an important question to answer. What is it that changes
>> that it causes Karen issues?
>>
>
> Indeed, that is Bell's problem that it MUST solve. If the transition has
> broken backwards compatibility (to use our lingo), they must fix the
> breakage. Their current digital-to-analog solution may work for many users
> (such as my landline) but clearly isn't sufficient for Karen's needs.
>
> The best possible solution is to find something that addresses Karen's
> requirement with a purely digital connection. Maybe it's a latency issue;
> remember how sensitive faxes were to even slightly unstable connections? I
> don't have any clue on the technical issues, but simply insist that the
> onus is on Bell to address them since they broke compatibility. I care less
> about "how" than that it gets done.
>
>

Well, then when someone who has a sense is trying to make sense of it,
don't attack them. The question being asked is "What is the gap?".  All the
other things, we cannot do anything about, they need to be fixed by Bell.


> While we are not medical professionals, we are engineers and it is our job
>> to solve the problem. In order to do that we do need to understand the
>> problem. This doesn't mean that Karen needs to participate in that process.
>> Maybe the medical professionals have an idea on what is getting affected
>> physically, but they are not engineers and they cannot comment on how to
>> answer the question on how to solve it.
>>
>
> The medical professionals are required to define the problem, ie the
> specifications required for their instruments to work properly. The comms
> engineers then need to solve that problem by whatever means necessary. We
> know that an analog solution using POTS works. Karen cannot simply be left
> behind by the move to digital.
>

Have the medical professionals defined it? No one is saying Karen should be
left behind. What folks are constantly asking for is to understand what the
gap is. There are defintions that are being met, standards that are being
met. This tells there is a gap. We need to identify the gap. But - you
cannot insist on providing technology for which spares do not exist. Is
your expectation that Bell manufacturer spares that are no longer
available? Who pays for it? Is it bell, is it our taxes, is it Karen? So
while I sympathize with where you are coming from, there may be real
constraints there.


>
>
>> If Karen's accessibility needs require analog service in 2023, then that
>>> service is not obsolete merely because it's convenient for Bell to declare
>>> it so.
>>>
>>
>> The service is obsolete because the technology is no longer being
>> actively maintained
>>
>
> I don't want to digress over semantics and definitions of "obsolete", see
> below.
>
> This doesn't absolve Bell of the responsibility to ensure accessibility
>> requirements are met. It just means the technology is obsolete.
>>
>
> If you agree that Bell has the responsibility to be backwards-compatible,
> then designations of "obsolete" are irrelevant.
>
> I am reminded (once again) of the brilliance of Jon Stewart's 2021 rant
> on the Colbert show 

Re: [GTALUG] Landline and Bell revisited.

2023-09-07 Thread Dhaval Giani via talk
On Thu, Sep 7, 2023 at 9:36 AM Evan Leibovitch via talk 
wrote:

> On Thu, Sep 7, 2023 at 11:40 AM James Knott via talk 
> wrote:
>
>
>> > Bell faces human rights complaint over allegations of inaccessibility for
>> blind customers
>> > https://globalnews.ca/news/9373449/bell-human-rights-complaint/
>>
>> This is about what Bell is not providing, even though other companies do.
>> However, this is current technology, not obsolete, which Karen seems to
>> need.
>>
>
> I call shenanigans on that perspective.
>
> Given the nature of our group it is natural that some here will see the
> issue as merely one of choice and pace of technology, but IMO it must be
> seen as a broader issue of problem-solving.
>

Evan, I did not read James' response in that vein. I read it as genuine
curiosity. Keep in mind that this group is primarily engineers/problem
solvers. And I think it is an important question to answer. What is it that
changes that it causes Karen issues? While we are not medical
professionals, we are engineers and it is our job to solve the problem. In
order to do that we do need to understand the problem. This doesn't mean
that Karen needs to participate in that process. Maybe the medical
professionals have an idea on what is getting affected physically, but they
are not engineers and they cannot comment on how to answer the question on
how to solve it.


> If Karen's accessibility needs require analog service in 2023, then that
> service is not obsolete merely because it's convenient for Bell to declare
> it so.
>

The service is obsolete because the technology is no longer being actively
maintained and all the development is happening elsewhere. This doesn't
absolve Bell of the responsibility to ensure accessibility requirements are
met. It just means the technology is obsolete. (For example, I would claim
Linux 2.6.32 is obsolete, but I can also find millions of IoT devices
running 2.6.32 which we probably want to secure).

Thanks!
Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] how many addresses possible

2023-04-29 Thread Dhaval Giani via talk
On Sat, Apr 29, 2023 at 13:04 o1bigtenor via talk  wrote:

> Greetings
>
> (My head is swimming with all the explanations on IP routing - - -
> have spent about 3 hours now looking at various documents - - - - I
> just can't find a clear answer. The first statement is my present
> network - - - I'm trying to figure out how to move beyond the access
> of only 254 devices at one time. Please - - - this is not my business
> - - - - I'm just using a highly connected system design idea in the
> planning and trying to figure out how to get what I would like - - -
> done. )
>
> If I set up a router using the 192.168.1.1 I can access some 254
> distinct IP addresses from my router.
>
> If I set up a router using the 176.10.1.1 how many distinct IP
> addresses can I access?
>
> (I'm thinking some 64k worth but dunno!)


You can access as many addresses as you want from your router. The address
block is determined by the subnet mask. Take a look at
https://en.wikipedia.org/wiki/Private_network

You will want to avoid 176, instead look at the 172.16. range or the entire
192.168.x.x range ( subnet mask will be 255.255.0.0)

Hope that helps

Dhaval


>
> TIA
> ---
> Post to this mailing list talk@gtalug.org
> Unsubscribe from this mailing list
> https://gtalug.org/mailman/listinfo/talk
>
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Fedora 38 is out

2023-04-22 Thread Dhaval Giani via talk
On Fri, Apr 21, 2023 at 23:55 Stewart Russell via talk 
wrote:

> On Fri., Apr. 21, 2023, 14:13 BCLUG via talk,  wrote:
>
>>
>>
>> I never, ever use fgrep or egrep and I think it's a bad idea.
>>
>
> Well, that's me told. I've used fgrep since the days when regular grep on
> a large file would take minutes, while fgrep would take seconds. I also
> learned egrep's slightly weird syntax at the same time. This was before
> PCRE was a thing. Before long-form options were a thing, too
>
> Deprecation of free software is so pointless. To break scripts for some
> imagined purity is flat-out daft.
>

I don’t know why you think so. There is a real cost to maintaining
software. Who is going to keep track of security issues? What about changes
to libraries you are linking to? Unless you are stepping up to maintain the
software, I think deprecating software is not only fine but necessary to
maintain security and quality.

Thanks
Dhaval


>
>  Stewart
>
>>
>>
>> ---
> Post to this mailing list talk@gtalug.org
> Unsubscribe from this mailing list
> https://gtalug.org/mailman/listinfo/talk
>
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Ubuntu Pro - a new, non-optional walled garden from Canonical

2023-01-31 Thread Dhaval Giani via talk
On Tue, Jan 31, 2023 at 8:22 AM Stewart Russell via talk
 wrote:
>
> I should really stop running Ubuntu for the good of my health. This morning, 
> my various Ubuntu systems announced that a whole bunch of packages would be 
> unavailable unless I registered for Ubuntu Pro — https://ubuntu.com/pro
>
> Ubuntu Pro is free-of-charge for "personal" users for up to five machines. 
> Otherwise, pay up. I didn't see rates listed: you have to contact Canonical 
> to find out. Whenever I see that, I expect an Oracle-style shakedown in the 
> absence of transparency.
>

https://ubuntu.com/pricing/pro
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Ubuntu review on Distrowatch

2022-05-02 Thread Dhaval Giani via talk
On Mon, May 2, 2022 at 9:35 AM William Park via talk  wrote:
>
> Yeah, I'm looking at Fedora too.  I just want something that is stable,
> that works after install, and will continue to work after upgrades for
> foreseeable future.  You can say that for Slackware.  But, I'm getting
> old for "manual transmission"...
>

As someone who will only install Fedora on his personal machines - and
has been using Fedora for 16 yrs now (I had to double check the dates
:-) ), I would really not recommend Fedora to someone who just wants
things to "work". I have never had an issue with something not
working, but I have almost always required some "advanced" level
tinkering at times with just a "dnf update". I lost wifi once because
for some reason, an update decided to get rid of all the firmware
files.

Another thing to keep in mind is - Fedora is fairly aggressive with
upgrades, and sometimes things are just, umm, unfinished, which again
breaks things. They do try to keep the upgrades under control within a
major release, but it is very maintainer dependent. And also, be
prepared to have workflow changes over major upgrades (and you do do
major upgrades frequently, because Fedora EOLs major versions fairly
aggressively).

And now I have a new, specced up laptop, but I can't get Fedora up on
it - because nvidia. Maybe when I have a few hours free to spend on
that.

Having said all of that, there is no other distro I would use for my
personal laptops.

Dhaval

> On 5/2/22 11:21, gs via talk wrote:
> > I think Fedora is on its way to becoming the replacement for Ubuntu as
> > the default recommended desktop distro based on the opinions of various
> > linux podcasts, youtubers and linux reddit communities.
> >
> > I'm happy with Manjaro but if I were choosing a new distro to move to,
> > it would be Fedora.
> >
> > --- Original Message ---
> > On Monday, May 2nd, 2022 at 4:36 AM, Evan Leibovitch via talk
> >  wrote:
> >
> >> Thanks. Ugh.
> >>
> >> Your timing is perfect, because I'm just about to do a fresh install
> >> and this would be the time to decide on something else.
> >>
> >> I'm looking for an alternative that will offer support for a KDE
> >> version as well as Steam and my fairly-new AMD graphics card (RX 6500
> >> XT). I'd also prefer to live snap-free.
> >>
> >> Mint and Pop don't support KDE, SuSE has problems with Steam and I'm
> >> exhausted enough that I don't want one more learning curve wrt the
> >> Arch way of doing things. Right now my best choices appear to be MX,
> >> KDE Neon (if I install the 32-bit libraries for Steam) and (if I want
> >> to go back to an RPM-based system for the first time since Mandriva
> >> ceased,) Fedora KDE.
> >>
> >> Any suggestions, either from these choices or something else? Thanks
> >> again.
> >>
> >> Evan Leibovitch, Toronto Canada
> >> @evanleibovitch / @el56
> >>
> >>
> >> On Mon, May 2, 2022 at 2:14 AM William Park via talk  >> > wrote:
> >>
> >> https://distrowatch.com/weekly.php?issue=20220502#ubuntu
> >> 
> >>
> >> [Last paragraph]
> >> I think the launch of Ubuntu 22.04 is a clear sign Canonical is much
> >> more interested in publishing releases on a set schedule than
> >> producing
> >> something worthwhile. This version was not ready for release and
> >> it's is
> >> probably going to be a costly endeavour to maintain this
> >> collection of
> >> mixed versioned software and mixed display server and mixed
> >> designs for
> >> a full five years. It's a platform I would recommend avoiding.
> >> --
> >> ---
> >> Post to this mailing list talk@gtalug.org 
> >> Unsubscribe from this mailing list
> >> https://gtalug.org/mailman/listinfo/talk
> >> 
> >>
> >
> >
> > ---
> > Post to this mailing list talk@gtalug.org
> > Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
> ---
> Post to this mailing list talk@gtalug.org
> Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Ubuntu 20.04.2 is groaning

2021-06-07 Thread Dhaval Giani via talk
On Mon, Jun 7, 2021 at 11:01 AM Chris Aitken via talk  wrote:
>
> On 2021-06-07 1:42 p.m., Howard Gibson via talk wrote:
> > On Mon, 7 Jun 2021 10:28:10 -0400
> > Chris Aitken via talk  wrote:
> >
> >> Hi,
> >>
> >> I am hoping to get some help with my Ubuntu 20.04.2 LTS system. Takes me
> >> 5+ seconds just to enter commands, switch between apps, etc.
> > Chris,
> >
> > My primary machines were having problems, slowing and stopping while 
> > stuff ran.  I fixed the problem by adding more RAM.  8GB on my desktop and 
> > 4GB on my laptop were not enough.  24GB and 16GB seem to be working fine.
> Does this show whether more RAM would help..?
>
> owner@owner-HP-Compaq-8000-Elite-CMT-PC:~$ free -h
>totalusedfree  shared buff/cache
> available
> Mem:  7.6Gi   2.5Gi   166Mi   209Mi 5.0Gi   4.7Gi
> Swap: 2.0Gi   696Mi   1.3Gi
>

166 MB free RAM. That might be a small problem! Find the memory hogs
and that might help. Though you might want to think about more RAM.

Dhaval

> >
>
> ---
> Post to this mailing list talk@gtalug.org
> Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Ubuntu 20.04.2 is groaning

2021-06-07 Thread Dhaval Giani via talk
On Mon, Jun 7, 2021 at 8:56 AM Val Kulkov via talk  wrote:
>
>
> On Mon, 7 Jun 2021 at 11:33, Chris Aitken via talk  wrote:
>>
>> Hi,
>>
>> I am hoping to get some help with my Ubuntu 20.04.2 LTS system. Takes me
>> 5+ seconds just to enter commands, switch between apps, etc.
>
>
> Try checking your hard disk's health with smartctl (package smartmontools). 
> Try replacing the hard disk's SATA cable.
>

Because I am terrible at reading comprehension.

Have you ruled out the usual suspects?

- How much RAM as you using?
free -h
will help check that out?

- Are you swapping?

- Are you using up too much CPU bandwidth? I prefer using htop to get
an ongoing view, but you could get those details from top. (Note - if
you have a multicore system like most of us do today, you will see CPU
consumption of more than 100%. As long as it is less than x*100 where
x is the number of CPUs, you should be "fine". To know the number of
CPUs, "lscpu" is a helpful command.)

- Are you having some CPUs getting oversubscribed. htop is more useful
in seeing this. If you see some CPUs running at 100% and others at
something lower, that might be something to investigate.

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Ubuntu 20.04.2 is groaning

2021-06-07 Thread Dhaval Giani via talk
Chris,

On Mon, Jun 7, 2021 at 8:33 AM Chris Aitken via talk  wrote:
>
> Hi,
>
> I am hoping to get some help with my Ubuntu 20.04.2 LTS system. Takes me
> 5+ seconds just to enter commands, switch between apps, etc.
>
> df reveals I have lots of space except what is dedicated to snap. I
> don't even know what snap is. Do I need snap. Whenever updates are
> offered I just accept them all, because I don't know the ramifications
> of refusing them. So, I may have accepted snap at some point.
>
> owner@owner-HP-Compaq-8000-Elite-CMT-PC:~$ df
> Filesystem 1K-blocks Used Available Use% Mounted on
> udev 39809080   3980908   0% /dev
> tmpfs 802092 1684800408   1% /run
> /dev/sda5  959862832 72588468 838446204   8% /
> tmpfs4010452  952   4009500   1% /dev/shm
> tmpfs   51204  5116   1% /run/lock
> tmpfs40104520   4010452   0% /sys/fs/cgroup
> /dev/loop0 5683256832 0 100% /snap/core18/1997
> /dev/loop1 5683256832 0 100% /snap/core18/2066
> /dev/loop4224256   224256 0 100% /snap/gnome-3-34-1804/66
> /dev/loop2166784   166784 0 100% /snap/gnome-3-28-1804/145
> /dev/loop3223232   223232 0 100% /snap/gnome-3-34-1804/60
> /dev/loop6 6668866688 0 100%
> /snap/gtk-common-themes/1515
> /dev/loop5 6643266432 0 100%
> /snap/gtk-common-themes/1514
> /dev/loop7 5235252352 0 100% /snap/snap-store/498
> /dev/loop8 5235252352 0 100% /snap/snap-store/518
> /dev/loop103289632896 0 100% /snap/snapd/11841
> /dev/sda1 5232484523244   1% /boot/efi
> /dev/loop113289632896 0 100% /snap/snapd/12057
> tmpfs 802088   88802000   1% /run/user/1000
>

https://snapcraft.io/about - to know more about snap

Beyond that - snaps (i am just guessing looking at your mountpoint and
details) look like just simple files mounted at a mount point. Since
these are probably ro files, you cannot write to them, and so it makes
sense available space of the snap is zero. The snap itself  seems to
be inside /snap.

Dhaval

>
> Chris Aitken
> ---
> Post to this mailing list talk@gtalug.org
> Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Linus Torvalds Responds to Linux Banning University of Minnesota

2021-04-25 Thread Dhaval Giani via talk
On Sun, Apr 25, 2021, 12:07 PM Karen Lewellen via talk 
wrote:

> I am not sure I resonate.
> why banning an entire university program for the actions of two students?
> Its like saying because one doctor abused his  duties, we will not let
> anyone seek care from St.  Michael's hospital ever again.
>

Rephrasing. If you knew about a doctor abusing patients at a hospital and
getting away with it, would you trust the hospital for your care or find
another one? Well there is a doctor at that hospital who has given you
excellent care in the past ( trust factor). So maybe you go to them then.

It is the same here. The University broke the trust factor. The IRB failed
to do it's job.

Dhaval


Or for a more computer reference Cloudflare's deciding I am a threat
> because I cannot solve their noninclusive captcha..they have a zero
> tolerance policy too.
>
>
>
> On Sun, 25 Apr 2021, Ansar Mohammed via talk wrote:
>
> > I know some people may think this is an over-reaction. But FWIW, I agree
> > with the Zero Tolerance approach.
> >
> >
> > On Sun, Apr 25, 2021 at 12:08 PM Dhaval Giani via talk 
> > wrote:
> >
> >> On Sun, Apr 25, 2021 at 8:32 AM D. Hugh Redelmeier via talk
> >>  wrote:
> >>>
> >>> | From: Aruna Hewapathirane via talk 
> >>>
> >>> Thanks for pointing this out.  (I used to subscribe to the LKML but it
> >>> just got too voluminous.)
> >>>
> >>> | I am still trying to understand the reason 'why' would anyone even
> >> want to
> >>> | do this ?
> >>>
> >>> The first question is "what, exactly, is 'this'?".
> >>>
> >>> I've ONLY read media reports and their recent apology.  So I'm not the
> >>> most informed.
> >>> <
> >>
> https://lore.kernel.org/lkml/cak8kejpuvlxmqp026jy7x5gzhu2yjlpu8sztzunxu2oxc70...@mail.gmail.com/T/#u
> >>>
> >>>
> >>> Some reactions.
> >>>
> >>> The apology starts with:
> >>>
> >>>   "We sincerely apologize for any harm our research group did to the
> >>>Linux kernel community."
> >>>
> >>> This common formulation rubs me the wrong way.  The word "any" means
> >>> that they are not actually admitting to there being harm.  If they had
> >> used
> >>> "the" or "all", I would interpret it as a genuine apology.
> >>>
> >>> Later they seem more contrite.  But it is buried at the end of a
> >>> paragraph, near the end of the message>
> >>>
> >>>   "We apologize unconditionally for what we now recognize was a breach
> of
> >>>the shared trust in the open source community and seek forgiveness
> for
> >>>our missteps."
> >>>
> >>> I think that they may have done the communities a service.  This kind
> >>> of weakness injection has always been available to bad actors.  In
> >>> this case, it was an actor intending to do good.
> >>>
> >>> - they don't think that they actually added a vulnerability
> >>>
> >>> - they demonstrated how adding a vulnerability could be done
> >>>
> >>> GKH appears to have over-reacted.  (I may be wrong: he's always seemed
> >>> like a rock-steady guy.)
> >>>
> >>
> >> As someone actually affected by these reverts :-). Greg KH did not
> >> over react. These guys did not do the community a service. They did
> >> add vulnerabilities (those have been reverted since) and they did not
> >> tell us anything. I myself have left old code in the kernel when
> >> trying to get rid of some of my stuff. And I was not trying to inject
> >> a bug. They did not tell me anything I did not already know. It is
> >> easy to get bugs into the kernel. Let me link to the paper and their
> >> "contributions".
> >>
> >>
> >>
> https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf
> >> --
> >> VIII A
> >> By its nature, OSS openly encourages contributors. Com- mitters can
> >> freely submit patches without liability. We believe that an effective
> >> and immediate action would be to update the code of conduct of OSS,
> >> such as adding a term like “by submitting the patch, I agree to not
> >> intend to introduce bugs.” Only committers who agreed to it would be
> >> allowed to go ahead to submit the patches. By int

Re: [GTALUG] Linus Torvalds Responds to Linux Banning University of Minnesota

2021-04-25 Thread Dhaval Giani via talk
On Sun, Apr 25, 2021, 11:27 AM Alvin Starr via talk  wrote:

> On 4/25/21 1:46 PM, Aruna Hewapathirane via talk wrote:
>
> On Sun, Apr 25, 2021 at 12:46 PM Ansar Mohammed via talk 
> wrote:
>
>> I know some people may think this is an over-reaction. But FWIW, I agree
>> with the Zero Tolerance approach.
>>
> Zero Tolerance allows one to live. They need to be shot !
>
> How about something like a go-fund-me kind of service that distributes the
> money to the successful contract killer?
>
> I am sure something can be done over a blockchain.
>
> If we could add in spammers I would be most happy.
>
>
Please don't even joke about that. I have friends who have received death
threats (on email and phone) and it is not the slightest bit funny.

Dhaval



> --
> Alvin Starr   ||   land:  (647)478-6285
> Netvel Inc.   ||   Cell:  (416)806-0133al...@netvel.net   
>||
>
>
> ---
> Post to this mailing list talk@gtalug.org
> Unsubscribe from this mailing list
> https://gtalug.org/mailman/listinfo/talk
>
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Linus Torvalds Responds to Linux Banning University of Minnesota

2021-04-25 Thread Dhaval Giani via talk
On Sun, Apr 25, 2021 at 8:32 AM D. Hugh Redelmeier via talk
 wrote:
>
> | From: Aruna Hewapathirane via talk 
>
> Thanks for pointing this out.  (I used to subscribe to the LKML but it
> just got too voluminous.)
>
> | I am still trying to understand the reason 'why' would anyone even want to
> | do this ?
>
> The first question is "what, exactly, is 'this'?".
>
> I've ONLY read media reports and their recent apology.  So I'm not the
> most informed.
> 
>
> Some reactions.
>
> The apology starts with:
>
>   "We sincerely apologize for any harm our research group did to the
>Linux kernel community."
>
> This common formulation rubs me the wrong way.  The word "any" means
> that they are not actually admitting to there being harm.  If they had used
> "the" or "all", I would interpret it as a genuine apology.
>
> Later they seem more contrite.  But it is buried at the end of a
> paragraph, near the end of the message>
>
>   "We apologize unconditionally for what we now recognize was a breach of
>the shared trust in the open source community and seek forgiveness for
>our missteps."
>
> I think that they may have done the communities a service.  This kind
> of weakness injection has always been available to bad actors.  In
> this case, it was an actor intending to do good.
>
> - they don't think that they actually added a vulnerability
>
> - they demonstrated how adding a vulnerability could be done
>
> GKH appears to have over-reacted.  (I may be wrong: he's always seemed
> like a rock-steady guy.)
>

As someone actually affected by these reverts :-). Greg KH did not
over react. These guys did not do the community a service. They did
add vulnerabilities (those have been reverted since) and they did not
tell us anything. I myself have left old code in the kernel when
trying to get rid of some of my stuff. And I was not trying to inject
a bug. They did not tell me anything I did not already know. It is
easy to get bugs into the kernel. Let me link to the paper and their
"contributions".

https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf
--
VIII A
By its nature, OSS openly encourages contributors. Com- mitters can
freely submit patches without liability. We believe that an effective
and immediate action would be to update the code of conduct of OSS,
such as adding a term like “by submitting the patch, I agree to not
intend to introduce bugs.” Only committers who agreed to it would be
allowed to go ahead to submit the patches. By introducing the
liability, the OSS would not only discourage malicious committers but
also raise the awareness of potential introduced bugs for benign
committers.
--
This is a mitigation. Have contributors claim they are not introducing
bugs (at least intentionally).

The rest of the mitigations are equally bizarre. They are not telling
us anything we don't know. There is nothing original in this work
(except for the human experimentation aspect of it.)

Now let's talk about the negative impact. It is already hard enough to
contribute to the linux kernel. It is built on trust. They have
destroyed any trust we had in code coming from UMN. How do we know we
are not being experimented for research? Like Greg pointed out, it is
much easier for us to ignore all their stuff. I don't have enough
seconds in my minute to get my day job done. On top of that, any new
comer will have to face a much higher bar, making it even more
hostile. (I actually see it as a negative, because it is easier to
ignore the newcomer as opposed to doing the extra work. And generally
most newcomers with some work turn out to be darn good contributors.)
It will make it harder to look at non corporate contributions
seriously.

And as far as UMN is concerned, this is not the first time they have
been involved in questionable experiments. The last time had much more
serious consequences.
https://en.wikipedia.org/wiki/Death_of_Dan_Markingson

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Google wins over Oracle in Java API copyright suit

2021-04-09 Thread Dhaval Giani via talk
>
> Call me old-fashioned, but I want my computers to do what I tell them. I
> don't want exceptions, I want results or error messages to explain why.
> I know there are many processes running that do things I'll never
> understand, but they must prove themselves useful to me or get out of my
> way.

Ha, and many programmers I know these days want the computer to get
out of the way, and functional programming gives them a way to do
that.

I think there are "niches" for both styles, and as pointed out
elsewhere, it does take a paradigm shift to do proper functional
programming. I could never achieve that, though I know folks who did,
and their code was quite elegant (in functional paradigm). Did make me
jealous at times when I had to write lots of procedural code. But,
hey, at least I knew exactly what happened and why and how (well, OK
most of the time) and functional programming was all magic to me.

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Google wins over Oracle in Java API copyright suit

2021-04-09 Thread Dhaval Giani via talk
On Fri, Apr 9, 2021 at 10:58 AM David Mason via talk  wrote:
>
> On Apr 9, 2021, 1:45 PM -0400, Stewart C. Russell via talk , 
> wrote:
>
> After all with a loop you are controlling the
> execution order of the processing.  If done right you usually shouldn't
> need to care.
>
>
> But in document processing, you really really /really/ want the output
> to come out in the same order as the input. Which is why functional
> languages seemed a strange choice for document transformation. The
> absence of side-effects can be handy in document processing, but being
> in the right order is usually what publishing houses get paid the big
> bucks to do.
>
>
> The key part of what Lennart wrote is “if done right”. How could you imagine 
> that the functional program would return the results out of order? 
> Compilers/interpreters are allow to make whatever optimizations they want, as 
> long as time and memory consumption are the only things that change from the 
> original!
>

I probably misread your statement. Compilers also routinely reorder
memory accesses as well, as long as the end result will not change.
Sometimes the cause for some fun to debug issues (in C/C++).
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Surveillance Capitalism [was another thread]

2021-04-02 Thread Dhaval Giani via talk
>>
>> Again, I say this again. RMS as a contributor, yes. RMS as a leader, no.
>>
>> I am not going to step into your Godwin's law discussion
>> (https://en.wikipedia.org/wiki/Godwin%27s_law ). It is irrelevant to
>> the issue at hand.
>
>
> That wasn't my discussion. I'm talking about Surveillance capitalism, which 
> grows
> more important to me day by day. I just think there is a lot of shooting the 
> messenger
> with RMS.
>

Then this thread should prove to you exactly why RMS cannot be your
messenger. You could be 100% factual, but it is what the other side
receives is of greater importance. Your cause is lost, when your
messenger causes your message to be lost.
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Surveillance Capitalism [was another thread]

2021-04-02 Thread Dhaval Giani via talk
> That's why I think Stallman should be allowed the benefit of the doubt, as a 
> person. His personal history seems to be
> one of family dysfunction and then finding comfort and direction in studies 
> in computer science at university.
>

Give him the benefit of the doubt. Just do not make him representative
of the movement.

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Surveillance Capitalism [was another thread]

2021-04-02 Thread Dhaval Giani via talk
Russell,

My assumption here is you are here in good faith as opposed to one of
those "white men are being persecuted" crowd. If you are the latter,
please let me know, I will send all future emails from you to
/dev/null.

On Fri, Apr 2, 2021 at 2:27 PM Russell Reiter  wrote:
>
> On Fri, Apr 2, 2021, 4:38 PM Dhaval Giani,  wrote:
>>
>> >
>> >> are all aware of. Many women were uncomfortable around RMS and avoided
>> >> him. Many refused to participate in our community because of
>> >> interactions with him. Do you think RMS is more important than a
>> >> community of developers he is pushing away?
>> >
>> >
>> > See all the stuff you say we are all aware in this message is just rumors 
>> > and innuendo to me.
>> >
>>
>> Wait, so all these women saying those words are rumours and innuendo?
>
>
> You know what, thats exactly what innuendo is, saying "all these women" 
> without even a link to a personal quote from them, not a one.
>
>> You choose to disbelieve them? After a pattern of behaviour that
>> multiple people have confirmed and talked about?
>
>
> I can't disbelieve that which I can find no record of. What multiple people 
> are you talking about?
>
> What I can do is check some facts, to the best of my abilities. This link I 
> came across in my opinion has a more balanced view than yours.

"In your opinion". In the opinion of many others, an apologist. If it
was a balanced article, why is there no link to the other petition?

>
> https://sterling-archermedes.github.io/
>

https://selamjie.medium.com/remove-richard-stallman-appendix-a-a7e41e784f88
- She has listed multiple (anonymous for obvious reasons) women who
are willing to talk about the toxic environment. It doesn't even begin
to count the numbers who are not, and would just wish it could go
away.

>>
>> > What are not rumors and innuendo are the historical facts on IBM, their 
>> > influence, their power and powerful friends and most importantly their big 
>> > ball of money which they spend on influenceing the influencers.
>> >
>> >>
>> >> I want to explicitly state this. RMS is a major reason free software
>> >> is where it is. RMS's contributions to free software are gigantic.
>> >> However, RMS cannot be a leader of our community if he continues to
>> >> isolate a significant population of prospective developers. RMS the
>> >> contributor - YES. RMS the leader - NO.
>> >>
>> >> RMS cannot be the poster child of our community if it is going to be
>> >> relevant in the future.
>> >
>> >
>> > This is where being the willing poster child of a charitable institution, 
>> > used to raise funds, diverges from the science of truth and innovation.
>> >
>> > In the legal science of truth, a person is innocent until proven guilty in 
>> > a court of law. However, media and the media barons in conteol, crucify 
>> > persons and their personas daily, just to make a buck.
>> >
>>
>> And no one has charged RMS with a crime. All we are saying is, he is
>> not representative of a majority of us, and we don't want him to
>> represent us. Some of us are minorities who have heard racist
>> statements being made by prominent folks in the community and have
>> made us feel our contributions are not valued. It is not hard to
>> believe after that experience that other prominent folks can be
>> sexist. RMS has not stepped up and owned up to his actions and
>> apologized. I have no problem with people growing. We all make
>> mistakes. But doubling down like this, well I don't want to be a part
>> of that community. And the reality is, there are tons of "other"
>> people who will not join in and we will never know. So yes, if the
>> choice is between thousands of those people, having a diverse
>> community, growing and being relevant to the world, I would rather RMS
>> step down than us lose this community. And I would rather you leave
>> the community if you think being more welcoming to other voices is not
>> important. We don't need your contributions at the risk of alienating
>> many more people.
>
>
> Wow that last paragraph was a completely off the wall projection of negative 
> personal attributes towards RMS without a shred of evidence. I wasnt aware 
> that Stallman was a deemed racist by association.
>

Stop for a moment. I said, knowing enough prominent folks who have
made racist statements, it is not hard for me to believe RMS could
have made sexist statements.

> Its bad enough that someone on this list deemed him to be an incel. Just type 
> incel into google and you can see the links to terrorisim.
>

And I believe a number of us called him out on that.

Russell, I made a good faith attempt to search for your contributions
to foss projects.  I have been unable to find anything. If you look at
https://rms-support-letter.github.io/ , that seems to fit the profile
of most signatories in there. https://rms-open-letter.github.io/ on
the other hand has prominent FOSS organizations, as well as a number
of prominent developers, many of whom I recognize.

Re: [GTALUG] Surveillance Capitalism [was another thread]

2021-04-02 Thread Dhaval Giani via talk
>
>> are all aware of. Many women were uncomfortable around RMS and avoided
>> him. Many refused to participate in our community because of
>> interactions with him. Do you think RMS is more important than a
>> community of developers he is pushing away?
>
>
> See all the stuff you say we are all aware in this message is just rumors and 
> innuendo to me.
>

Wait, so all these women saying those words are rumours and innuendo?
You choose to disbelieve them? After a pattern of behaviour that
multiple people have confirmed and talked about?

> What are not rumors and innuendo are the historical facts on IBM, their 
> influence, their power and powerful friends and most importantly their big 
> ball of money which they spend on influenceing the influencers.
>
>>
>> I want to explicitly state this. RMS is a major reason free software
>> is where it is. RMS's contributions to free software are gigantic.
>> However, RMS cannot be a leader of our community if he continues to
>> isolate a significant population of prospective developers. RMS the
>> contributor - YES. RMS the leader - NO.
>>
>> RMS cannot be the poster child of our community if it is going to be
>> relevant in the future.
>
>
> This is where being the willing poster child of a charitable institution, 
> used to raise funds, diverges from the science of truth and innovation.
>
> In the legal science of truth, a person is innocent until proven guilty in a 
> court of law. However, media and the media barons in conteol, crucify persons 
> and their personas daily, just to make a buck.
>

And no one has charged RMS with a crime. All we are saying is, he is
not representative of a majority of us, and we don't want him to
represent us. Some of us are minorities who have heard racist
statements being made by prominent folks in the community and have
made us feel our contributions are not valued. It is not hard to
believe after that experience that other prominent folks can be
sexist. RMS has not stepped up and owned up to his actions and
apologized. I have no problem with people growing. We all make
mistakes. But doubling down like this, well I don't want to be a part
of that community. And the reality is, there are tons of "other"
people who will not join in and we will never know. So yes, if the
choice is between thousands of those people, having a diverse
community, growing and being relevant to the world, I would rather RMS
step down than us lose this community. And I would rather you leave
the community if you think being more welcoming to other voices is not
important. We don't need your contributions at the risk of alienating
many more people.

Again, I restate this. RMS as a contributor - yes. RMS as a leader -
no. He doesn't represent me, and he certainly doesn't represent the
community of foss developers. This is a discussion about RMS, not the
conspiracy theories you are throwing about.

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Surveillance Capitalism [was another thread]

2021-04-02 Thread Dhaval Giani via talk
Russell,

I think we are capable of judging the two cases independently.

Instead of the conspiracy theories. Let's look at the one fact that we
are all aware of. Many women were uncomfortable around RMS and avoided
him. Many refused to participate in our community because of
interactions with him. Do you think RMS is more important than a
community of developers he is pushing away?

I want to explicitly state this. RMS is a major reason free software
is where it is. RMS's contributions to free software are gigantic.
However, RMS cannot be a leader of our community if he continues to
isolate a significant population of prospective developers. RMS the
contributor - YES. RMS the leader - NO.

RMS cannot be the poster child of our community if it is going to be
relevant in the future.

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] The FOSS world's most famous incel is back...

2021-03-24 Thread Dhaval Giani via talk
Hi,

Without taking names, I would suggest participants on this thread take
a look at https://gtalug.org/about/code-of-conduct/ .

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] War Story: debugging remote port access

2021-03-22 Thread Dhaval Giani via talk
On Mon, Mar 22, 2021 at 10:26 AM Michael Galea via talk  wrote:
>
> On 2021-03-22 8:09 a.m., Stewart C. Russell via talk wrote:
> > On 2021-03-22 12:53 a.m., Michael Galea via talk wrote:
> >>
> >> The only problem I have encountered is that if mpd starts before nfs
> >> mounts, it doesn't see the collection.
> >
> > Doesn't the mpd systemd service wait for network? It did the last time I
> > installed it on a Raspberry Pi for an audio project.
> >
> > cheers,
> >   Stewart
> > ---
> > Post to this mailing list talk@gtalug.org
> > Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
> >
> That, unfortunately, has not been my experience.  I am on the 0.19.1-1.1
> version, which I installed in 2016 from raspian. Maybe things have
> improved since then in other mainline distros.
>
> How would mpd know to wait? The config just specifies the hard path that
> mpd uses to read audio files from. It would have to know when nfs
> actually mounts.
>

systemd should be able to take care of this for you. Just set a
dependency on the mount itself and it should magically happen.

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] question re: bug filing

2021-02-17 Thread Dhaval Giani via talk
On Wed, Feb 17, 2021 at 6:52 PM o1bigtenor via talk  wrote:
>
> On Wed, Feb 17, 2021 at 7:28 PM Lennart Sorensen via talk
>  wrote:
> >
> > On Wed, Feb 17, 2021 at 03:12:49PM -0800, Dhaval Giani via talk wrote:
> > > I also imagine you are paying the debian volunteers for their time to
> > > help you with a bug you are hitting. You are joining a community, and
> > > it would be great to respect the rules and processes that community
> > > follows. Seriously, this is a volunteer effort people are involved in.
> > >
> > > FWIW, reportbug is *NOT* monitoring your system. It is just populating
> > > your bug report with almost everything the maintainer would ask you up
> > > first. Such as, are you on the latest package? Can you test with the
> > > latest package? Has your bug already been reported? If so, can we add
> > > to that report? Are you running the originally shipped package or
> > > doing something custom?
> >
> > Yes the debian bug reporting is a script collecting info.  It can send it
> > directly as an email, if email sending is configured on your system, or it
> > can save it as a file you can send from an email client by yourself, and
> > of course being a text file you can read what it in it before sending it.
> >
> Reading the 'official' Debian page on 'reportbug' really didn't even seem to
> hint that sending anything in myself was possible. There were directions on
> setting up this and that and the next thing and everything was supposed to
> then 'just happen' (an automatic function). There was also no mention of
> any limits in the 'sending'. Like does it function autonomously after the 
> first
> time, that seemed to be what was suggested - - - - but - - - - - it
> really wasn't
> clear.
>

Try harder.  Hugh suggested https://www.debian.org/Bugs/Reporting .
Opening that page,

How to report a bug in Debian using email (and advanced usage of reportbug)

followed by

Sending the bug report via e-mail

Nowhere does it say you can only use reportbug. Yes, they prefer bugs
reported through that, but you can always email bugs.

> Any tool that doesn't have clearly defined limits usually doesn't get 
> installed
> here. My trust factor in software isn't very high - - - - if it even
> exists in all
> honesty - - - that's called experience.

Just to remind you here, this is free software. The source code is
available to you to satisfy your paranoia.

> In fact I have four systems - - - one
> main computer and an older server - - - - don't use it much but bought it
> looking forward. Then there is a test bed system for each of the first two.
> There are still issues that happen because the test bed system for my main
> machine isn't multi-gpu and multi-monitor so I 'have' been trying to set up
> things to minimize my main system(s) being taken out because of software
> but even this trialing system isn't detailed enough. Its starting to seem
> like I need to have my trial system be more similar to its counterpart.
> I just don't have the time to fight to get things working well after I do a
> system upgrade and those issues are taking at least part of my system
> down even 3 to 4 days. Kernel 5.0.5 was far worse there were times I
> had to do a reboot every few hours - - - hard to get work done when you
> need about 1/2 hour to set up things the way you want them and then
> within a few hours you need to do it all over again.
>
> So what do I do - - - - no clear path at this point yet except perhaps to
> install kernel 5.4.99 (last time I looked at the kernel info) and then run 
> that,
> maybe I can keep that kernel and just update everything else - - - dunno.
>

Engage the debian community, and describe your problem. Let them
figure out where the issue is. Respect the person at the other end and
remember, they are doing you a favour. And that you are not entitled
to that support. If you take this attitude there, I am very sure you
will just get ignored. If that is not possible, pay someone to fix it
for you. Of course, there is the other option of using some other
software (proprietary because it would meet your requirements better,
and you have paid for support). No one is forcing you to use Debian
(or free software for that matter).

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] question re: bug filing

2021-02-17 Thread Dhaval Giani via talk
On Wed, Feb 17, 2021 at 6:35 PM o1bigtenor  wrote:
>
> > Dhaval
> On Wed, Feb 17, 2021 at 5:14 PM Dhaval Giani  wrote:
> >
> > On Wed, Feb 17, 2021 at 3:09 PM o1bigtenor via talk  wrote:
> > >
> > > On Wed, Feb 17, 2021 at 2:17 PM D. Hugh Redelmeier via talk
> > >  wrote:
> > > >
> > > > | From: D. Hugh Redelmeier via talk 
> > > >
> > > > | Each distro has its own way of reporting bugs
> > > >
> > > > I forgot to mention: google a lot first.  There may be others with the
> > > > same problem and perhaps even a solution.
> > >
> > > 1. You're still using google for a search engine - - - - - wow - - - - can
> > > I introduce you to Duckduckgo? So far, at least, they're not not 
> > > harvesting
> > > your data and all your searches.
> > > 2. A multi-gpu and multi-monitor system on LInux is considered very 
> > > extreme
> > > fringe. Almost all the upper level coders seem to find that more than one
> > > gpu is no fun so they run maybe 2 monitors. Its not the same thing when 
> > > you
> > > get to multi-gpu AND multi-monitor. Those with serious technical expertise
> > > just don't seem to run this kind of stuff.
> > >
> > > The gamers, well they're into monitor latency and not into screen real 
> > > estate,
> > > what used to be called the power user - - - - in (and on) LInux is 
> > > considered
> > > not worth wasting time on - - - so finding expertise - - - - -
> > > incredibly difficult.
> > >
> >
> > If it is worth your time, maybe you can develop the expertise. We
> > welcome you to contribute to the community.
> >
> Haven't found any interest - - - - in fact mostly the opposite.
>

No you misunderstand. Clearly you, o1bigternor, have the interest. So
go develop the skill and write code for the bugs/issues you are
hitting. You know almost every open source contribution starts with
scratching your own itch. And if you don't want to do that, pay
someone enough money so they take care of your itch.

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] question re: bug filing

2021-02-17 Thread Dhaval Giani via talk
On Wed, Feb 17, 2021 at 6:34 PM o1bigtenor  wrote:
>
> On Wed, Feb 17, 2021 at 5:13 PM Dhaval Giani  wrote:
> >
> > On Wed, Feb 17, 2021 at 3:04 PM o1bigtenor via talk  wrote:
> > >
> > > On Wed, Feb 17, 2021 at 12:53 PM D. Hugh Redelmeier via talk
> > >  wrote:
> > > >
> > > > | From: o1bigtenor via talk 
> > > >
> > > > | Kernel 5.4.0-4 was the last kernel where I didn't find my second
> > > > | graphics card not able to move out of sleep.
> > > >
> > > > Each distro has its own way of reporting bugs.  Here's an unofficial
> > > > description of the debian process (untested by me -- I don't use
> > > > debian):
>
> > I also imagine you are paying the debian volunteers for their time to
> > help you with a bug you are hitting. You are joining a community, and
> > it would be great to respect the rules and processes that community
> > follows. Seriously, this is a volunteer effort people are involved in.
> >
> There are a lot of these 'official' volunteers that are working day jobs that
> strangely are very very like their volunteer interests.
>

That still doesn't explain why you feel entitled to free support.
Someone is paying them to do specific things in the distro. The fact
that the interests align is just a happy coincidence. I am sure if you
were to provide enough incentive, someone's interests will align with
yours.

> When I was beating my head against the wall for over 2 months when I
> first set up this system the amount of information available or offered to
> me was close enough to zero so as to make it a moot point for open source
> support.
> In the years since I've found that most coder types really don't get into
> screen real estate - - - - in fact some serious programmers were still using
> 19" monitors (within the last year) where I had moved to a 1600x1200 crt
> some 20 years ago.
> Horses for courses except I've far too often found my screen real estate
> far too confining when I'm working on something complicated. All of what
> I've found only reinforces the point that what I'm doing is w   ay
> out there!
>

If you are the one user, why do you expect a project to spend
thousands of hours ensuring something is not broken for you?
Especially since you claim, it is very different from what "most coder
types" use/do. Again, all I am hearing is entitlement, and honestly if
I were the maintainer of that project, I would point out that no one
is forcing you to use my project, and no one is stopping you from  (or
paying someone to) contributing code to the project to take care of
your use case. If there is something out there that is better, use it.

> > FWIW, reportbug is *NOT* monitoring your system. It is just populating
> > your bug report with almost everything the maintainer would ask you up
> > first. Such as, are you on the latest package? Can you test with the
> > latest package? Has your bug already been reported? If so, can we add
> > to that report? Are you running the originally shipped package or
> > doing something custom?
> >
> Interesting - - - - the one thing that you don't mention and that I think
> might be the case here is that the actual bug may be a specific confluence
> of things. So even with a complete listing of all of what you have - - - - the
> actual problem still isn't visible. I spent a few hours reading through files
> in /var/log/  and haven't been able to find anything. Which is why I was
> asking for assistance in where to ask. (The assumption seems to be
> that I don't have any idea - - - - and maybe I don't . . . .   .)
>

No. The assumption here is you are expecting free support on your
terms. We have pointed out multiple ways, pointed out the falsehoods
in your statements. Again, all the steps I listed in my earlier note
are what just about any maintainer is going to ask you to do before
even thinking about your problem. Once we know you are on the latest,
and the issue you have is not fixed, then we try fixing it. Because
let's be real, if it is already fixed, why should I fix it again?
Again, you are NOT going to get support on your terms. If you want it
that way, pay someone and then you get that right (and maybe even then
not).

Dhaval

> Regards
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] question re: bug filing

2021-02-17 Thread Dhaval Giani via talk
On Wed, Feb 17, 2021 at 3:09 PM o1bigtenor via talk  wrote:
>
> On Wed, Feb 17, 2021 at 2:17 PM D. Hugh Redelmeier via talk
>  wrote:
> >
> > | From: D. Hugh Redelmeier via talk 
> >
> > | Each distro has its own way of reporting bugs
> >
> > I forgot to mention: google a lot first.  There may be others with the
> > same problem and perhaps even a solution.
>
> 1. You're still using google for a search engine - - - - - wow - - - - can
> I introduce you to Duckduckgo? So far, at least, they're not not harvesting
> your data and all your searches.
> 2. A multi-gpu and multi-monitor system on LInux is considered very extreme
> fringe. Almost all the upper level coders seem to find that more than one
> gpu is no fun so they run maybe 2 monitors. Its not the same thing when you
> get to multi-gpu AND multi-monitor. Those with serious technical expertise
> just don't seem to run this kind of stuff.
>
> The gamers, well they're into monitor latency and not into screen real estate,
> what used to be called the power user - - - - in (and on) LInux is considered
> not worth wasting time on - - - so finding expertise - - - - -
> incredibly difficult.
>

If it is worth your time, maybe you can develop the expertise. We
welcome you to contribute to the community.

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] question re: bug filing

2021-02-17 Thread Dhaval Giani via talk
On Wed, Feb 17, 2021 at 3:04 PM o1bigtenor via talk  wrote:
>
> On Wed, Feb 17, 2021 at 12:53 PM D. Hugh Redelmeier via talk
>  wrote:
> >
> > | From: o1bigtenor via talk 
> >
> > | Kernel 5.4.0-4 was the last kernel where I didn't find my second
> > | graphics card not able to move out of sleep.
> >
> > Each distro has its own way of reporting bugs.  Here's an unofficial
> > description of the debian process (untested by me -- I don't use
> > debian):
> >
> >   
> >
> > Here's official documentation:
> >
> >   
>
> Hmmm - - - interesting - - - - in this area Debian is sounding a lot
> like M$ - - - - "please setup this system so that we can monitor your system
>  or . . .   ." and there seems to be no other way to report bugs .
> As I don't do that for anyone  - - - - - sounds like I am going to not be on
> debian for much longer. (I'm easy - - - - you work with me - - - or
> I'm history.)

I also imagine you are paying the debian volunteers for their time to
help you with a bug you are hitting. You are joining a community, and
it would be great to respect the rules and processes that community
follows. Seriously, this is a volunteer effort people are involved in.

FWIW, reportbug is *NOT* monitoring your system. It is just populating
your bug report with almost everything the maintainer would ask you up
first. Such as, are you on the latest package? Can you test with the
latest package? Has your bug already been reported? If so, can we add
to that report? Are you running the originally shipped package or
doing something custom?

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] odd evince command behaviour

2021-01-07 Thread Dhaval Giani via talk
On Thu, Jan 7, 2021 at 12:04 PM D. Hugh Redelmeier via talk
 wrote:
>
> | From: Dhaval Giani via talk 
>
> | On Thu, Jan 7, 2021 at 11:32 AM D. Hugh Redelmeier via talk 
>  wrote:
>
> | > Also:
> | > evince 'RE\: something.pdf'
> | > fails because evince tries to open a file with \ in its name.
> |
> | That is because within the single quotes, it will not use the \ as an
> | escape character. I'm unsure of the behaviour within double quotes.
>
> OK, my model is that there are two entities that are doing
> quoting/globbing/etc.
>
> 1. the shell
>
> 2. the application program (evince) itself.
>
> This second is un-UNIX-like behaviour.  But common in other operating
> systems.
>
> The single quotes are not seen by 2.  They are interpreted by 1.
>
> But I established that the RE: was being handled (mishandled) by 2.
>
> So I wanted a "quote" function for 2.  I tried \ but 2 did not treat
> it as a metacharacter.
>
> There might be a quote function for 2 but I don't know it.
>
> There are applications that make interpretations of filenames but this
> often creates problems.
>

OK, good point. Can you run a strace on evince and see how it is
calling open on that file?

> - if a filename looks like a flag argument, applications will try to
>   handle it as a flag argument.  Many applications provide a workaround
>   this with a - flag argument which means "treat the rest of the arguments
>   as filenames, even if they start with -"
>
> - scp interprets hostname:filename as just that.  This means that 'RE:
>   something.pdf" will be a problem for scp.  Solution: prepend with ./
>
> I don't know what evince is trying to do.

Just out of curiosity. When you try to use shell autocomplete using
the tab key, what does it autocomplete to?

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] odd evince command behaviour

2021-01-07 Thread Dhaval Giani via talk
On Thu, Jan 7, 2021 at 11:32 AM D. Hugh Redelmeier via talk
 wrote:
>
> | From: Dhaval Giani via talk 
>
> | On Thu, Jan 7, 2021 at 10:58 AM D. Hugh Redelmeier via talk 
>  wrote:
>
> | > This fails:
> | > evince "RE: someting.pdf"
> |
> | Stupid question, does replacing " with ' help? IIRC ' does no
> | substitution at all. And it just feels like an escape issue. Does it
> | think RE is a protocol due to the ":" there. Maybe you can also try to
> | escape that ":" and see if it opens.
>
> Good suggestion.  No, using ' instead of " doesn't change what happens.
> So this is evince trying to handle RE: as magical.
>
> Also:
> evince 'RE\: something.pdf'
> fails because evince tries to open a file with \ in its name.

That is because within the single quotes, it will not use the \ as an
escape character. I'm unsure of the behaviour within double quotes.

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] odd evince command behaviour

2021-01-07 Thread Dhaval Giani via talk
On Thu, Jan 7, 2021 at 10:58 AM D. Hugh Redelmeier via talk
 wrote:
>
> I have a PDF filename named "RE: something.pdf"
>
> This fails:
> evince "RE: someting.pdf"

Stupid question, does replacing " with ' help? IIRC ' does no
substitution at all. And it just feels like an escape issue. Does it
think RE is a protocol due to the ":" there. Maybe you can also try to
escape that ":" and see if it opens.

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Looks like IBM is planning to eliminate RHEL

2020-08-05 Thread Dhaval Giani via talk
On Wed, Aug 5, 2020, 11:04 AM Russell Reiter  wrote:

> Hey Phoronix got me through some kind of puzzling stuff relatively
> unscathed. I just liked some of the more pointed comments from this
> article, like its either RPM and reboot or Flatpak from the cloud.
>

Ha, no offense meant at phoronix. It is their brand of click baity
headlines I am not a fan of. Their performance suite is something that is
useful taken in context. I just wish they would do something more
substantial and take it to the next level. You see all the great
ingredients and then the work is left as an exercise to the reader ;-).

Techrights however, I won't even bother.


> I never personally used MS much past dos 6.2. I think thats because I got
> a late start in computing and was exposed to Linux early on. I think I
> joined tlug in 95 or 96 and settled into Red Hat. So like most people, I
> poke fun at the things that scare me, like having to learn a whole new OS
> updating mechanisim. Or having to fudge rpm packages into apt updates.
>
> Cheers
>
> Russell
>
> “Th’ newspaper does ivrything f’r us. It runs th’ polis foorce an’ th’
> banks, commands th’ milishy, controls th’ ligislachure, baptizes th’ young,
> marries th’ foolish, comforts th’ afflicted, afflicts th’ comfortable,
> buries th’ dead an’ roasts thim aftherward.” F. P. Dunne
>
>
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Looks like IBM is planning to eliminate RHEL

2020-08-05 Thread Dhaval Giani via talk
On Wed, Aug 5, 2020, 6:43 AM Russell Reiter via talk 
wrote:

> This is sad. But the article is an interesting backgrounder on the
> internal chaos thats leading up to this.
>
> "They said that OS development was knocked down to lowest priority,” Ryan
> noted. It says it right there. That may explain quite a lot, not just about
> RHEL’s direction but also Fedora’s. We see more vendor tie-in/lock-in, more
> software patents (monopoly) and not much of real value."
>
> IBM is Already Gutting Red Hat and Firing Employees Without Warning, Jim
> Whitehurst Isn’t Even Using GNU/Linux | Techrights
>
> http://techrights.org/2020/08/02/red-hat-layoffs/
>
>
>

I was once reading that site and it accused Greg kh and Sasha Levin of
being Microsoft stooges. I knew enough about it then. (Fun bit I think he
reads it for entertainment to see what they will come with next).

Seriously, even phoronix is a serious news site compared to that one.

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] btrfs weirdity.

2020-06-29 Thread Dhaval Giani via talk
On Tue, Jun 23, 2020 at 4:28 PM Dev Guy via talk  wrote:

> I don't like btrfs, this seems to be the default fs for the boot
> partition with openSUSE Tumbleweed and I think on 2 occasions it got
> messed up so bad that I stop using it.
>
> Anything is better than btrfs, even fat32 which I ended up using for the
> boot partition! Been running solid with no issues upgrade after rolling
> upgrades.
>
>
People love talking smack about btrfs. Here's some real insight from Josef
Bacik though at
https://lwn.net/ml/fedora-devel/03fbbb9a-7e74-fc49-c663-32722d6f7...@toxicpanda.com/
and
https://lwn.net/ml/fedora-devel/cf5b4944-74c4-b4a4-0d65-71d9821a4...@toxicpanda.com/.
Read through the chain. For those who don't know him, Josef is a core btrfs
developer. I also quite like Josef personally, he is a good developer,
great to work with and is personally invested in helping folks out.

This is a solid fs, there are times when I see the reactions from users and
I really wonder why I do open source work anyway. I have lost data on all
sorts of filesystems, and I have also been at the end of stupid mistakes
made. Almost everything is recoverable if you stop, and ask for help and
keep your ego out of it.

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Raspberry Pi 4 with 8G of RAM

2020-05-28 Thread Dhaval Giani via talk
>
>
>
> > On Thu, 28 May 2020 at 12:57, Andrew Heagle via talk  > > wrote:
> >
> > 64bit version of Raspbian (Now apparently renamed to Raspberry Pi
> > OS) in beta also released.
>
> Note that it's very beta: much desktop acceleration isn't available yet.
>
>
Maybe a plug here
https://www.oracle.com/linux/downloads/linux-arm-downloads.html

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Laptop recommendations?

2020-04-24 Thread Dhaval Giani via talk
While not a recommendation, this just popped up on LWN

https://fedoramagazine.org/coming-soon-fedora-on-lenovo-laptops/

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] security threats of Open Source

2020-01-23 Thread Dhaval Giani via talk
Hugh,

On Thu, Jan 23, 2020 at 11:08 AM D. Hugh Redelmeier via talk <
talk@gtalug.org> wrote:

> <
> https://www.zdnet.com/article/microsoft-spots-malicious-npm-package-stealing-data-from-unix-systems/
> >
>
> This article list six cases of malware contributed to npm (the repo for
> sharing node.js and JavaScript source).
>
> How many undetected cases exist?
>
> I've alway pretended that Linux distros vet their code.


They do, but npm is different. npm is indepdent of the distro itself. And
people want to use npm because it gives them the latest and the greatest.


>   I'm not sure how
> true that is.  Probably the greatest protection is the time delay between
> contribution and distribution.
>
>
I would be wary of this approach. There are a bunch of security fixes,
where you probably don't want too long a delay. Part of responsibility also
lies on the user to validate the update. With it being open source, and a
"volunteer" model, some of that has to be accepted b the user.

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] [OT] Phishing is no mirage...

2019-12-18 Thread Dhaval Giani via talk
On Wed, Dec 18, 2019 at 4:48 AM Russell Reiter via talk 
wrote:

> On Tue, Dec 17, 2019, 2:57 PM Alvin Starr via talk 
> wrote:
>
>> On 12/17/19 2:27 PM, Russell Reiter via talk wrote:
>> [snip]
>>
>>
>>
>>> | I wonder why, especially in this data stealing age, the practice is
>>> not firmly
>>> | against the law?
>>>
>>> Yes.  And the boundaries clearly marked.
>>>
>>
>> The problem is that its a matter of private law. The government would
>> essentially fetter itself if it actually made it illegal for you to give
>> out your SIN voluntarily. This might be the case in settlement if someone
>> has sued you, won and now has the right to a full accounting of your income
>> and assets.
>>
>> Enforcing laws is expensive and there is a threshold which is bounded by
>> economy of scale. As a general matter of private law, caveat emptor (let
>> the buyer beware) is the rule.
>>
>> Its kind of like the government is a national park with a grand canyon
>> running through it. The can put up signs which say don't get too close to
>> the edge or you may fall in but they can't really stop you from jumping off
>> the edge.
>>
>>
>> Its not that I was giving out my SIN voluntarily. It was a requirement of
>> getting service from a telecom provider.
>> Yes I could have refused to fill out the the application and walked out
>> of the store.
>> But then I would not have had the telecom service that I needed at the
>> time.
>>
>
> Yes you did volunteer the information when they asked for it. The law
> presumed you have a choice in the matter. There are enough providers who
> don't collect SIN numbers that you could have used one of them. You jumped
> into the canyon by wanting services immediately. There is an old saw that
> says decide in haste, repent at leisure.
>
>
Russell, I disagree with you here. When someone new to Canada  comes over,
they do not know what is true or not. I recall refusing to provide my SIN
when I moved to Canada (because I was aware) to rogers, and I had to put in
additional deposit (note, it was a deposit, but not an additional fee). If
you were to have suggested teksavvy at that time, i would have laughed you
away, because in the beginning I want something that is "bigger and
therefore safer". The law is meant to protect the vulnerable, and folks who
are new to Canada are probably the most vulnerable to predatory practices
(simply because they don't know when they can or can not push back. They
may also not have the financial resources to put in that bigger deposit
that a service provider wants). You, Alvin, Hugh and I are in a group of
people who understand their rights and are willing to psuh back. The
newcomers are still learning, and this is a first bad impression they get
of our country.

And, let's be honest. We do not do a good job of talking about why the SIN
is important. You cannot have SIN used as identity as well as verification.
How do I know when it is and it is not OK to give your SIN? Why do you need
SIN as a proof of identity for a credit check? It can be an identifier, but
give me some other "verification" means, which I control. Doesn't that take
away a lot of issues that a SIN leak causes?

I would rather not blame the victim here, especially when the victim is a
more vulnerable class that represented on this list.

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] alternatives to gmail working well in Ubintu?

2019-11-15 Thread Dhaval Giani via talk
On Fri, Nov 15, 2019 at 8:24 AM Karen Lewellen via talk  wrote:
>
> sorry James, i did not realize you were using adaptive technology.
> May I ask how you will manage once Google, as they plan, block all third
> party  screen readers?
> Sorry if I seem frustrated, but I asked a very specific question, not to
> have   my choices dismissed because you do things differently.
>

Karen,

I am sorry, I don't have a suggestion for you. However, I did a  quick
search and couldnt find mention about Google blocking third party
screen readers. Do you have a link? I was not aware of it, and this is
certainly the wrong direction for accessibility and probably needs to
be spread about.

Beyond that, I am trying to understand your requirements, to make an
informed suggestion. Why is basic html getting hard to read? Does it
have something to do with the layout, or is it something deeper?

Thanks!
Dhaval

>
>
> On Thu, 14 Nov 2019, James Knott via talk wrote:
>
> > On 2019-11-14 10:00 PM, Karen Lewellen via talk wrote:
> >>  I was going to just ask for alternatives to consider, but want to keep the
> >>  Linux element here as I mainly use a Ubuntu shell.
> >>  Now that google is making it  profoundly difficult reaching basic html in
> >>  low graphics environments, I may need a new home.  I prefer reading on
> >>  the web for this account, especially as I use it largely for research
> >>  needing to follow article links and work with file attachments.
> >>  Any solid ideas?
> >
> > I prefer using an email client such as Seamonkey or Thunderbird, to a
> > browser.  They work fine.
> >
> > ---
> > Post to this mailing list talk@gtalug.org
> > Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
> >
> >---
> Post to this mailing list talk@gtalug.org
> Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Linux kernel 5.3.0

2019-09-20 Thread Dhaval Giani via talk
On Fri, Sep 20, 2019 at 5:00 AM David Collier-Brown via talk
 wrote:
>
>
> On 2019-09-19 11:11 p.m., William Park via talk wrote:
>
> I just tried kernel 5.3.0, and it's noticeably faster in opening
> windows.  Not sure about overall throughput, though.
>
>
> I'd be interested in how quick it is in unblocking processes who just got 
> I/O. I have servers doing arrays of heavily parallel network requests who 
> race each other to get back, but then compete to get a core to service them.
>

Ha, you might be interested in the latest thing we are working on
upstream. We discussed it last week at Linux Plumbers. We are calling
it latency-nice (but as all good programmers know, naming is hard and
this will probably change).

Right now the scheduler is not too good at figuring out which process
should get a place to run at quickly, and by providing a latency-nice
tunable, you can ensure your latency sensitive processes are placed on
the runqueue quickly.

Keep an eye out for this, hopefully we will get it upstream in a few months.

Dhaval

> --dave
>
> --
> David Collier-Brown, | Always do right. This will gratify
> System Programmer and Author | some people and astonish the rest
> dav...@spamcop.net   |  -- Mark Twain
>
> ---
> Post to this mailing list talk@gtalug.org
> Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Suspend/resume not working with latest kernel in Debian unstable/sid

2019-09-16 Thread Dhaval Giani via talk
On Mon, Sep 16, 2019 at 4:45 PM Daniel Wayne Armstrong via talk
 wrote:
>
> On my old C720 Chromebook, in the past I have needed to add 
> `GRUB_CMDLINE_LINUX_DEFAULT="tpm_tis.force=1"` to GRUB to enable 
> suspend/resume to work properly in Debian.
>
> After a fresh re-install and upgrade to Debian unstable/sid, suspend/resume 
> is not working with kernel 5.2.9-2. System will suspend, but trying to resume 
> results in a hard reboot. I think the problem is with tpm_tis.
>
> Messages in the log upon boot ...
>
> ```
> $ journalctl -b | grep tpm
> Sep 16 18:18:01 cruithne kernel: tpm_tis tpm_tis: 1.2 TPM (device-id 0xB, 
> rev-id 16)
> Sep 16 18:18:01 cruithne kernel: tpm tpm0: tpm_try_transmit: send(): error -5
> Sep 16 18:18:01 cruithne kernel: tpm tpm0: A TPM error (-5) occurred 
> attempting to determine the timeouts
> Sep 16 18:18:01 cruithne kernel: tpm_tis tpm_tis: Could not get TPM timeouts 
> and durations
> Sep 16 18:18:01 cruithne kernel: tpm_tis 00:08: 1.2 TPM (device-id 0xB, 
> rev-id 16)
> Sep 16 18:18:01 cruithne kernel: tpm tpm0: tpm_try_transmit: send(): error -5
> Sep 16 18:18:01 cruithne kernel: tpm tpm0: A TPM error (-5) occurred 
> attempting to determine the timeouts
> Sep 16 18:18:01 cruithne kernel: tpm_tis 00:08: Could not get TPM timeouts 
> and durations
> Sep 16 18:18:01 cruithne kernel: tpm_inf_pnp 00:08: Found TPM with ID IFX0102
> ```
>
> Suspend/resume *does* continue to work with kernel 4.19.67-2 (current default 
> in Debian stable). Messages in the log ...
>
> ```
> Sep 16 18:00:38 cruithne kernel: tpm_tis 00:08: 1.2 TPM (device-id 0xB, 
> rev-id 16)
> Sep 16 18:00:38 cruithne kernel: tpm tpm0: [Firmware Bug]: TPM interrupt not 
> working, polling instead
> ```
>
> Removing the "tpm_tis.force=1" line from GRUB when booting into kernel 
> 5.2.9-2 makes no difference.
>
> A google search with "tpm tpm0" "tpm_try_transmit" "error -5" "A TPM error 
> (-5) occurred attempting to determine the timeouts" returns NO hits. Dropping 
> the last term is a bit more successful but still leads me to no solution.
>
> Any ideas how I might get this to work with the latest kernel 5.2*? Thanks in 
> advance!
>

Mind sending me your dmesg offlist?

For both the new and the old kernel (after resume for the old one please)

Dhaval

> --
> Daniel Wayne Armstrong  https://www.circuidipity.com
> Accomplish the great task by a series of small acts. -- Lao Tzu
>
> ---
> Post to this mailing list talk@gtalug.org
> Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Linux Kernel Allows 0.0.0.0/8 as a Valid Address Range

2019-08-15 Thread Dhaval Giani via talk
On Thu, Aug 15, 2019 at 4:13 PM Val Kulkov via talk  wrote:
>
> On Wed, 14 Aug 2019 at 13:33, Russell Reiter via talk  wrote:
> >
> >
> > I imagine the energy map of the day might bear striking similarity to this 
> > map of adoption of ipv6 by country.
> >
> > https://www.google.com/intl/en/ipv6/statistics.html
> >
> > It will be interesting to see how it all works out.
> >
>
> While seemingly promoting adoption of IPv6 Google refuses to implement
> DHCPv6 in Android OS. See this article:
> https://www.techrepublic.com/article/androids-lack-of-dhcpv6-support-frustrates-enterprise-network-admins/
>

I seem to have my Pixel 3 pick up an IPv6 address via DHCP.

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Script to show HTTP(S) and TLS details for a website

2019-08-11 Thread Dhaval Giani via talk
On Sat, Aug 10, 2019 at 8:46 AM Giles Orr via talk  wrote:
>
> This may be seen as self-promotion - that's not totally wrong.  But I think 
> this may also be useful to others and (as I acknowledge in the blog post) I'm 
> quite pleased with the resultant script.
>
> Over the past year and a half I've slowly developed a shell script that gives 
> a concise summary of the state of TLS and HTTP(S) on a given website.  It 
> looks like this:
>
> $ tlsdetails google.ca
> Using OpenSSL:  /usr/bin/openssl
> Expiry Date:Oct 27 17:27:07 2019 GMT (78 days)
> Issuer: Google Trust Services, CN
> TLS Versions:   tls1_3 tls1_2 tls1_1 tls1  (tried but unavailable: ssl3 
> ssl2 )
> HTTP Version:   2
>
> I first started work on it after a couple embarrassing certificate expiries.  
> It then grew to check the Issuer, TLS versions, and more recently whether or 
> not a site supports HTTP2.
>
> (The pointer to the OpenSSL version is shown because the script will also run 
> on Mac, and their version of 'openssl' is problematic at best.  That line is 
> of course easy to remove if you don't like it.)
>
> If you're interested, you can find the details here:
>
> https://www.gilesorr.com/blog/tls-https-details.html
>
> Any suggestions to improve the script would be most welcome.
>

This is pretty cool work! My only suggestion would be to slap a
license on it. Even if it is a BSD style one, it makes it very clear
what you believe acceptable use to be.

Thanks!
Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] A find alternative: fselect

2019-06-17 Thread Dhaval Giani via talk
On Mon, Jun 17, 2019 at 7:46 AM Lennart Sorensen
 wrote:
>
> On Thu, Jun 13, 2019 at 10:06:37PM -0700, Dhaval Giani via talk wrote:
> > I agree with you on this, but also seeing how some libraries get
> > developed/updated (I am looking you, npm), I can see why some
> > programmers prefer static libraries.
>
> But npm is one of those modern eco systems that believes every project
> should pick its own version of everything.  It is effectively static
> linking.
>

Well, yes. Mainly because of the way people update libraries. (or hand
ownership).

> So npm is the static linking problem.
>

More like worst of both worlds.

> --
> Len Sorensen
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] A find alternative: fselect

2019-06-13 Thread Dhaval Giani via talk
> >
> > Shared libraries significantly reduce the size of programs.  Rust
> > binaries are probably quite a bit larger than C binaries.
>
> Go has the same design flaw.  Giant static binaries.
>
> Amazing how many new programing languages don't want to pay attention
> to history and the security lessons already learned.
>

I agree with you on this, but also seeing how some libraries get
developed/updated (I am looking you, npm), I can see why some
programmers prefer static libraries.

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] A find alternative: fselect

2019-06-13 Thread Dhaval Giani via talk
> HOWEVER, since Rust code is intrinsically much, much safer than C code, 
> stability of API is much more legitimate a characterizer of the version that 
> you want than bug-fixes (and bug-fixes are almost never security/safety 
> related).

Please please please. Bug fixes, specifically the ones that get
shipped fairly quickly, are almost always security related. Security
bugs are just a class of bugs.

Also, till I see some way of formally verifying, that rust code is
safe enough that security issues are not possible, remind me to be
quite sceptical of the claim that Rust code is secure. In the last two
years, we have seen classes of bugs believed to be impossible.

I will accept your claim that in the hands of an average programmer,
Rust is probably safer, but we have enough experience with C/Assembly,
that I am gonig to claim that with someone experienced, they can
create as secure/safe programs in C, as experienced folks in Rust.
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] NUC NUC NUC

2019-05-21 Thread Dhaval Giani via talk
On Tue, May 21, 2019 at 11:20 PM Lennart Sorensen
 wrote:
>
> On Tue, May 21, 2019 at 10:13:22PM +0200, Dhaval Giani wrote:
> > This led me on chase, because Intel friends suggested what I said. I
> > haven't looked too closely yet to see the difference between i3/i5/i7,
> > but both i3/i5 do NOT have HT as per ark.intel. If i were to make a
> > guess about the difference between i3/i5, I would go towards the turbo
> > boost capability. But it is late where I am, and I am speaking early
> > tomorrow morning :-), so I will look into it tomorrow, and probably
> > ask a couple of Intel folks here.
>
> There are only a few i3 models that have 4 actual cores.  Almost all are
> 2 core with hyperthreading.  The i5 on the other hand was almost always
> 4 cores (now 6 cores on the latest generation) without hyperthreading.
> There were a few low end models that were exceptions and were configured
> like the i3 with 2 cores and hyperthreading.  So for the i3 hyperthreading
> was the norm and for the i5 hyperthreading was the exception.
>
> https://en.wikipedia.org/wiki/List_of_Intel_Core_i3_microprocessors
> https://en.wikipedia.org/wiki/List_of_Intel_Core_i5_microprocessors
>
> At the high end the i7 always had hyperthreading until the latest
> generation where some no longer do (the i9 does though).  Apparently 8th
> gen i7 with 6 cores and hyperthreading is replaced by 9th gen i7 with 8
> cores and no hyperthreading.
>

I am looking at

https://ark.intel.com/content/www/us/en/ark/products/192990/intel-core-i9-9980hk-processor-16m-cache-up-to-5-00-ghz.html
-> Has SMT
https://ark.intel.com/content/www/us/en/ark/products/191047/intel-core-i7-9850h-processor-12m-cache-up-to-4-60-ghz.html
-> Has SMT
https://ark.intel.com/content/www/us/en/ark/products/191051/intel-core-i5-9600t-processor-9m-cache-up-to-3-90-ghz.html
-> Doesn't have SMT
https://ark.intel.com/content/www/us/en/ark/products/191126/intel-core-i3-9350kf-processor-8m-cache-up-to-4-60-ghz.html
-> Doesn't have SMT

(I just picked the first one in each list, so obviously I haven't
looked deeper into it).

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] NUC NUC NUC

2019-05-21 Thread Dhaval Giani via talk
On Tue, May 21, 2019 at 5:46 PM Lennart Sorensen
 wrote:
>
> On Tue, May 21, 2019 at 01:05:34AM +0200, Dhaval Giani via talk wrote:
> > Honestly, the latest round of flaws are nothing special. For most
> > desktop use case, I wouldn't worry. It is very difficult to exploit
> > it. If you are really worried, go for something like an i3, which is
> > essentially an i5 with HT disabled. I would be worried about several
> > easier to exploit issues before worrying about MDS or L1TF. (Meltdown
> > was different, but newer CPUs already have it fixed in hardware).
> > Something like Spectre affects every single modern CPU which does
> > speculative execution and we will be fighting it for a long long time.
> >
> > (Of course, if you are in a cloud environment, the situation is different).
>
> Actually the i5 has no HT, the i3 always does.  The i5 is essentially
> an i7 with HT off.
>

This led me on chase, because Intel friends suggested what I said. I
haven't looked too closely yet to see the difference between i3/i5/i7,
but both i3/i5 do NOT have HT as per ark.intel. If i were to make a
guess about the difference between i3/i5, I would go towards the turbo
boost capability. But it is late where I am, and I am speaking early
tomorrow morning :-), so I will look into it tomorrow, and probably
ask a couple of Intel folks here.

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] NUC NUC NUC

2019-05-20 Thread Dhaval Giani via talk
> Perhap AMD flaws haven't been discovered yet.  But the current score
> shows AMD ahead.
>

This. The cynic in me though goes, that's a bad thing. Because no one
thinks at this point in time that AMD is worth exploiting, and who
knows what is lurking there.

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] NUC NUC NUC

2019-05-20 Thread Dhaval Giani via talk
> Evan: From a security point of view (Rowhammer, Fallout, RIDL, ZombieLoad 
> ...) I would encourage you to consider an AMD processor.  (Or better yet, ARM 
> - but that's not really viable on the desktop yet.)  AMD isn't totally immune 
> to the plethora of recent attacks, but it's a lot better off.  (I say this, 
> but I'm writing you from an 8th gen i7 bought in the middle of that series of 
> appalling revelations.)
>

Honestly, the latest round of flaws are nothing special. For most
desktop use case, I wouldn't worry. It is very difficult to exploit
it. If you are really worried, go for something like an i3, which is
essentially an i5 with HT disabled. I would be worried about several
easier to exploit issues before worrying about MDS or L1TF. (Meltdown
was different, but newer CPUs already have it fixed in hardware).
Something like Spectre affects every single modern CPU which does
speculative execution and we will be fighting it for a long long time.

(Of course, if you are in a cloud environment, the situation is different).

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


[GTALUG] snapd (was Re: Installing Anaconda with Python 3 on 32 bit linux (Ubuntu ver 16.04 ))

2019-04-20 Thread Dhaval Giani via talk
> > | To whit - -
> > | Canonical has moved to this system in their implementations of both
> > | snapd and also lxd. It is possible to reduce the frequency of the upgrades
> > | from a daily inspection and possible update/upgrade to a maximum of
> > | a month long period without update/upgrade.
> >
> > Are you saying that updates are mandatory, but only for snapd and lxd?
> > That sounds a bit odd.
> >
> > Is it only security updates that are mandatory?
>
> Snapd is used to install lxd.

Do you need snapd to install lxd? Doesn't apt-get install lxd do it for you?

> >
> > I don't use snapd and lxd.  Abstractly, both need to bridge between an 
> > inside
> > environment and an outside one.  Are the updates purely to the
> > inside, to the outside, or both?  Could the updates be required to
> > make this bridging correct?
>
> Not sure - - - just know that snapd can be set for an update/upgrade once
> a month. If that doesn't happen - - - well my system (Debian 9) would shut
> itself down.

This led me to, umm, blink. Debian forcing updates? That is most non
debian behaviour I have heard of. Some  googling around led me to the
conclusion that it is not Debian mandating the updates, but instead
snapd.

Snap is a "universal package manager" for Linux. One of its key
features is, you will always be running "updated" software. I can see
where it can be useful (really in container deployments, where you
could be running some ancient piece of software, and leaving unpatched
security holes).

I don't see why it needs to be running on "managed" systems
(essentially systems where you are actively administering and applying
updates as needed).

Do you mind me asking what the rationale was behind installing snapd?
Or is it just installed by default (sort of hard to believe that
Debian won't be looking to fix that mistake).

> >
> > I thought that one of the goals of snapd and of container systems was
> > the decouple versioning of inside and outside.  What other purpose is
> > there for snapd, for example?
>
> My guess is that this tightly coupled behavior would make it much easier
> to create a fee for such connection. This then monetizes the software.
> Both of these 'technologies' development occur after Canonical was rumored
> to be contemplating an IPO.

I would not go with the conspiracy theory. There is a push towards
containers, and standardization of package managers and updates is a
problem that needs to be solved.

> >
> > | I found out the hard way that this was a MUST from the software. Myself
> > | I prefer to update/upgrade periodically - - - usually checking to make 
> > sure
> > | that the software isn't going to get borked because the upgrade has flaws
> > | in it (even more fun when the system gets borked due to flaws in the
> > | software!!). It was suggested that it would be possible to skirt around 
> > the
> > | constant update/upgrade cycle by using a firewall rule to hinder the 
> > forced
> > | reach out from my system to 'mother ship'. Well that joy set up a system
> > | that after such an update/upgrade request was blocked - - - well the 
> > system
> > | would shut itself down. It was only after the second such incident that I
> > | started investigating and by the fourth I could call the trend. Now I have
> > | the issue of having directories that I am unable to remove even using rm 
> > -r
> > | but there is a very long and definitely not simple technique whereby maybe
> > | I will be able to purge my server of said mess.
> >
> > Wow.
> >
> > It would be interesting to know what the rationale for this is.
> > There's a chance that the reason is reasonable.
>
> The rationale - - - stated is to make sure that the user never has outdated
> software. (Implied is that users are the major issue causing software
> problems.) Not explained is why there is a need to run software on the
> bleeding edge. There just is no room left for something like Debian stable
> or software that is rock solid stable - - - there were a number of interesting
> bugs that showed up.

There are very good reasons to be running on the latest. Especially in
community distros, where there isn't a full time team to analyze and
backport fixes to the distro. You might not be an average user, but
the average user doesn't understand how different bugs can be
exploited, and if it is easy to update the package, then that is the
right thing. And if something else that it depends on breaks, that
software should be fixed. Most library developers I know are very
careful about not breaking software that depends on them. When a
breaking change does happen, it is publicised and deprecated with
enough time for applications to update themselves. If they don't I
don't have too much sympathy for them being broken :-). So, if you are
on a community distro, and updating frequently, then this shouldn't
matter to you. If you are not the average user, and do understand the
risks involved, then either you are updating the library/application

Re: [GTALUG] Boeing India software engineers

2019-03-13 Thread Dhaval Giani via talk
On Wed, Mar 13, 2019 at 5:05 PM Gary  wrote:
>
> Dhaval, your dim view of the Indian value chain is unfounded because
> India is now ranked 3rd in A.I. research. Indeed, if you're higher up in
> the value chain in North America then you certainly do run the risk of
> losing your job because, for example,  A.I. research has to be pretty
> high up in the value chain I would suspect!!
>
> https://www.analyticsindiamag.com/ai-ml-research-breakthroughs-india/
>

Gary,

I am getting close to assuming malicious intent in your statements
right now. I have at no point in time put forth a dim view in the
indian value chain. Instead you have lowered the value of indian chain
by saying they will do it for cheap. I have constantly been advocating
for friends back in India to charge the same prices that people here
charge for the same skills. Why not? It is the same job. Please go and
reread what I said. Once you go up the value chain, you are able to
command the same dollar value, and that's when the risk of you losing
your job reduces.

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Boeing India software engineers

2019-03-13 Thread Dhaval Giani via talk
On Wed, Mar 13, 2019 at 5:01 PM James Knott via talk  wrote:
>
> On 03/13/2019 11:59 AM, Dhaval Giani via talk wrote:
> > And whose responsibility is that? The market will support what it
> > will. I pay my share of taxes to ensure that those who can't support
> > themselves are not left behind.
>
> And then we have people like Doug Ford, who cut taxes for the wealthy,
> while cutting support for those who need it.
>

well, that's a whole new can of worms, and I am not getting there :-).
Hopefully there is still an Ontario at the end of it :-)/


Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Boeing India software engineers

2019-03-13 Thread Dhaval Giani via talk
On Wed, Mar 13, 2019 at 4:53 PM James Knott via talk  wrote:
>
> On 03/13/2019 11:49 AM, Dhaval Giani via talk wrote:
> > So, if you are higher up the value chain, you are not going to lose
> > your job anytime soon.
>
> Out of the population, how many will be higher up the value chain?  What
> do the rest do?
>

And whose responsibility is that? The market will support what it
will. I pay my share of taxes to ensure that those who can't support
themselves are not left behind.

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Boeing India software engineers

2019-03-13 Thread Dhaval Giani via talk
On Wed, Mar 13, 2019 at 4:49 PM James Knott via talk  wrote:
>
> On 03/13/2019 11:22 AM, Dhaval Giani wrote:
> > What is this "good stuff" that is moving offshore? From what I can
> > see, stuff that is higher up the value chain is still in North
> > America, and is still going to remain here. And for a very simple
> > economic reason. It costs the same $ value.
>
> Well, I mentioned 3, IT, lab tests and law.  There are others.
>
> For many years, we were promised get an education and you'll always have
> a job.  It appears that no longer holds true as many areas, such as
> those I mentioned, are moving offshore.  What is someone starting out
> today supposed to do?  What will be the next area moved offshore?  Even
> some trades, such as aircraft maintenance are going.  We're heading into
> a situation where more and more people will be unable to support
> themselves.  Take a look at the news to find out about things like wage
> & wealth inequality, people unable to afford a decent place to live or
> even put food on the table.  And then look at where the money is going.
> Look at the super wealthy.  I mentioned Walmart.  In the U.S. they pay
> many of their employees so poorly that they need social assistance just
> to live.  One figure I recall was that each Walmart employee in
> Wisconsin costs the taxpayers some $4K per year.  Let's not forget that
> this is one of the wealthiest families in the U.S. being subsidized by
> the taxpayers.  One example of many.
>
> When people talk of cutting costs, they all too often forget about the
> cost of cutting costs.  Guess who it is that all too often is forced to
> pay for these "savings".
>

Well sure, and the US is a more complex case than just cost cutting.
Offshoring is just one part of it. The other problem is how the
immigration system works. In the name of protecting US jobs, you tie
work permits to just one company, and artificially lower salaries.
With free movement of labour, you are forced to pay market salaries.
Why should a company pay for an expensive visa, if the person will
just move to the next high paying job, when they can hire locally?

Another problem is that people are not willing to pay the actual cost
of the goods. If you are to pay the actual cost of labour, the prices
are quite a bit higher. An example is a restaurant meal. That labour
cost is subsidized by tipping. Either we be ready to pay the actual
cost, or we will continue seeing these shenanigans.

(Still does not excuse the insane profit margins, but the reality is
that as soon as these companies become more humane, the shareholders
will drop these companies and the value will drop and our pensions
will also drop)

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Boeing India software engineers

2019-03-13 Thread Dhaval Giani via talk
On Wed, Mar 13, 2019 at 4:46 PM Gary  wrote:
>
> No, I think YOU have misunderstood. When I download lectures I do so for
> the sole purpose of entertainment and nothing more; I'm a senior
> citizen. My thinking was that those individuals who enjoy science and
> engineering can still indulge that interest and yet support themselves
> with jobs that are unlikely to be outsourced. The alternative case of
> spending a lot of money on a science or engineering degree to learn
> science, which is their passion, just does not make sense because the
> hope of establishing a career in the field before it gets outsourced is
> unfounded in view of the fact that places like India have very talented
> people who can do the job, do it better and work cheap!

I don't understand why you keep ignoring what I keep saying.

1. There are talented people everywhere
2. There are people who do things equally well and equally badly everywhere
3. For high quality work, no one works cheap.

So, if you are higher up the value chain, you are not going to lose
your job anytime soon.

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Boeing India software engineers

2019-03-13 Thread Dhaval Giani via talk
On Wed, Mar 13, 2019 at 4:21 PM Gary via talk  wrote:
>
> Well, as I had indicated in an earlier email, it is a fact that from a
> U.S. census 74% of those with STEM degrees do not work in STEM. This is
> my authority.
>
> However, even IEEE says that the "tech shortage" is just a myth:
> https://spectrum.ieee.org/at-work/education/the-stem-crisis-is-a-myth
>
> https://www.thestar.com/opinion/commentary/2014/05/13/how_the_myth_of_a_canadian_skill_shortage_was_shattered_goar.html
>
> https://www.techrepublic.com/article/the-myth-of-the-tech-talent-shortage-why-its-a-much-smaller-problem-than-vendors-say/
>

Gary,

I think you misunderstand what Alex says. How is it different saying
"only vocational training is worthwhile because spending money getting
an academic degree is useless" from "you don't need vocational
training, you can learn plumbing from youtube?". That is the ignorance
he is calling out.

I can attest to that. These are some very specialised fields. I have
worked with some very smart people, who have reinvented 50 year old
research because they don't have the academic CS background, and
refuse to learn from those mistakes. This is why you see software
becoming slower again :-).

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Boeing India software engineers

2019-03-13 Thread Dhaval Giani via talk
On Wed, Mar 13, 2019 at 4:12 PM James Knott via talk  wrote:
>
> On 03/13/2019 10:59 AM, Dhaval Giani via talk wrote:
> > James Knott wrote
> >
> > "
> >> Several years ago, many companies decided to cut costs by moving help
> >> desks etc. to India.  Many have come to regret that decision, due to the
> >> poor quality "help".  In another thread, I mentioned how many put cost
> >> ahead of value and we get garbage as a result.
> > "
>
> My comments are about how we were promised that if we moved into areas
> such as IT, we'd be set for life.

I fail to see how I can reach the conclusion you want me to by reading
your comment.

> The low cost work, such as
> manufacturing cheap goods would be done offshore.  Well, it appears more
> and more of the good stuff is also moving offshore.

What is this "good stuff" that is moving offshore? From what I can
see, stuff that is higher up the value chain is still in North
America, and is still going to remain here. And for a very simple
economic reason. It costs the same $ value.
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Boeing India software engineers

2019-03-13 Thread Dhaval Giani via talk
On Wed, Mar 13, 2019 at 3:51 PM Gary  wrote:
>
> I think you've misconstrued the intent of our discussion.

o1bigtenor wrote

"
> A number of years ago I read that India is generating more engineers per year
> that the rest of the world combined. How good they are - - - - that's
> another question.
"

James Knott wrote

"
> Several years ago, many companies decided to cut costs by moving help
> desks etc. to India.  Many have come to regret that decision, due to the
> poor quality "help".  In another thread, I mentioned how many put cost
> ahead of value and we get garbage as a result.
"

mwilson wrote

"
> A friend of mine had a job from hell for a while as Canada-side overseer
> of an India-based programming effort.  The job entailed being up all night
> to oversee, then being up all day explaining to management what was
> happening in India.  He's a smart, talented guy, but really, how good is
> *anybody* going to be working like that?
"

I am unsure how I have misconstrued the intention up there.

> The issue is
> worldwide labour arbitrage where production moves to the lowest cost
> region.  This is a reality that must be fully appreciated by those
> contemplating a career in North America. As you allude to in your
> rebuttal, it is a basic economic argument that is apparently lost on the
> massive hordes pursuing degrees  in computer science in this country.

And you have completely missed another important bit. None of the
important work is leaving the US (and as an extension North America).
If your job is leaving North America, that means you are not providing
enough value. These jobs pay the same either here, or there, in
absolute $ values, which is why they stay here. What goes away is
stuff that doesn't need much.

> No
> one here is trying to cast aspersions on the quality of Indian workers;
> rather, we see India as an up and coming force in the world by virtue of
> their favourable demographics. However, I don't believe that this view
> has been fully understood in this country.

Maybe you are saying that. That is not however what this thread is saying.

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Boeing India software engineers

2019-03-13 Thread Dhaval Giani via talk
On Wed, Mar 13, 2019 at 3:10 PM Gary via talk  wrote:
>
> I believe the short answer is that if you live in North America, you
> should avoid wasting money on a costly academic education, even if
> you're very gifted, and, instead, focus on vocational training that can
> never be outsourced, such as postal work, fire fighter, ambulance
> paramedic and medical laboratory services. In that way there is a clean
> bifurcation in the nature of work that is carried out between here and
> India.
>
> In this wonderful age, you don't have to spend a penny indulging your
> interest in computer science, technology, physics and mathematics as you
> have internet resources for that purpose. For example, I'm a retired
> postal clerk but I entertain myself by downloading lectures on these
> topics. I've taught myself c++ and I have lots of fun developing
> applications in Linux. I have a passion for A.I and mathematics but I
> know that, if you live in this country then these studies can never be
> more than an indulgence, unless you have really good connections; but
> then, in that case, you can just get a degree in medieval history before
> taking the helm as CEO at some company, which is what Carly Fiorinas did
> with HP.
>
> https://www.usnews.com/news/blogs/washington-whispers/2014/09/30/carly-fiorinas-medieval-history-major-inspires-young-female-conservatives
>
> /gary

I am not even going to begin by saying how wrong and how racist this
entire topic is.

I have worked with enough poor indian developers. I have also worked
with enough poor highly paid canadian, american and european
developers. They exist everywhere regardless of nationality.

I also worked with enough indian developers whose work would be
classified as poor while in India which magically turned to pretty
good when they started working in the US. I have also heard
interesting things being said by developers here about people in India
which spoke to how blind they were about situations outside of
Canada/US/Europe. (Part of it being, oh, open source is not about
passion to people in India, it is just a job. Well, it is, you know,
because they need food on their plates).

I am horrified that we are sitting here and talking about this.

If you are in the industry, then you are very much aware that is
mostly the grunt work that gets outsourced. If your job is getting
outsourced, then more likely than not, you are not that high up the
value chain. Sorry to break the news to you. Is it a nice thing? No,
absolutely not. I would not wish it on anybody. But the reality is, it
is basic economics. If it can be done for cheaper, and it is not
essential, "quality" (whatever that means), doesn't matter. Don't
begrudge whoever won that. Increase your own value. If you are doing
something essential, your job is not going to go  away any time soon.
Let's not be racist and pick on someone other nationality.

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] video: Benno Rice on "The Tragedy of systed"

2019-02-08 Thread Dhaval Giani via talk
> > The notion in "Dockerworld" of having minimal containers where you
> > don't have a lot of extra crap that you're packing into the containers
> > is appealing, but I'm not sure how under control this is.
> >
> > What does it mean to "keep system up to date?"  There's just enough
> > philosophical oddness to that that I'm left sufficiently off-put by it
> > all.
>
> Well to Canonical it means that you will be updating your system at
> least every month - - - their preference is every day but you can back
> it off to once a month. If you try to shut that 'feature' off - - - - life 
> does
> get interesting (which is why I want nothing to do with it as a result!).
>

I know I am walking into this one. Why do you not want to update your
system on a regular basis?

Bugs will always be there (including whatever you are running). The
distro I work for, we try to limit updates to once a month, since we
recognize the fact that customers cannot always reboot on a whim.
Having said that, those updates are fairly important, and should be
applied as soon as possible. Most distros won't foist a new version on
you, it will be a stable update. Also, if you don't trust the distro's
update and testing, why are you using that distro in the first place?
Why not build something of your own?

Let's not get into a situation where we are not updating our systems
and running with known vulnerabilities, which normally have exploits
already available.

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Questions on wireguard and networking

2018-10-03 Thread Dhaval Giani via talk
On Wed, Oct 3, 2018 at 7:54 AM James Knott via talk  wrote:
>
> On 10/03/2018 10:36 AM, o1bigtenor via talk wrote:
> > Found what looks to be a quite interesting vpn 'system' called wireguard.
>
> "WireGuard^® is an extremely simple yet fast and modern VPN that
> utilizes *state-of-the-art cryptography
> *. It aims to be faster
> , simpler
> , leaner, and more useful than
> IPSec, while avoiding the massive headache. It intends to be
> considerably more performant than OpenVPN."
>
> Be very, VERY careful about cryptography that hasn't been extensively
> verified by experts.  Even ones that have still have flaws discovered
> occasionally.
>

*THIS*

Having said that, the good news about wireguard is not around those.
The author of wireguard understands that and has implemented using
well tested/verified algorithms. It is mostly around how it has
currently been implemented. The last I saw on that, the wireguard
authors are working on fixing the crypto side of things before the
networking side will be reviewed. People are interested in getting it
in, it will just take time before it is mainline.

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Linux 4.19-rc4 released, an apology, and a maintainership note

2018-09-17 Thread Dhaval Giani via talk
On Mon, Sep 17, 2018 at 12:52 PM D. Hugh Redelmeier via talk <
talk@gtalug.org> wrote:

> | From: Dhaval Giani via talk 
>
> | https://lwn.net/Articles/764901/
>
> |
> https://www.jonobacon.com/2018/09/16/linus-his-apology-and-why-we-should-support-him/
>
> Thanks.  I hadn't noticed this.  A possibly big story.
>
> | On a more personal note, I have seen "hostile" behavior on many mailing
> | lists, which has led me from withdrawing from participating on them.
>
> Mailing lists are notoriously bad at communicating emothions.  I guess
> that causes some to just amp things up.  There have been many
> discussions of this phenomenon and I still don't have great insights.
>
> I have not found this mailing list to be a problem.  Have you?
>
>
Troubling patterns, yes. Not to me, not projects I participate in. But I
have noticed them. I debated about bringing it up, and then decided that it
wasn't worth my time or effort for clearly negligible gain.


> Be conservative in what you do, be liberal in what you accept
> from others.
>
> Jon Postel
>
> Some things can seem like slights even when there was no such intent.
>
>
I agree. You do however have to account for the fact that most software
development is a negative feedback loop (find bug, debug, fix, rinse,
repeat..). Add doing that in public, almost everything starts coming out
negatively.

A friend of mine had an interesting insight on this a few years back.
Paraphrasing him, written communication is always is read as more negative
than what it is written as. So, you have to write it as 2x postive for it
to be read as 1x positive.

Is it a sustainable goal, I am unsure. But I do think it is a problem.


> Death threats are hard to explain away.  I did not read Linus' comment
> about abortion to be a deat threat.  Just overly colourful swearing.
> I did not think it appropriate.  "Criticize the sin, not the sinner."
>
>
I think different incidents. Lennart (not Linus), had someone call him and
leave him a death threat. (He had shared the recording with me at that time)


> This has low reliability, so take it with a large grain of salt, but
> the only time I met Lennart Poettering (before systemd) he did seem
> arrogant.
>
>
I don't think that though is a reason to belittle him.


> I've not made any contributions to the kernel / netdev.  I've found the
> processs daunting / unwelcoming.  At least one "lieutenant" has been
> much more unpleasant than Linus.  Just fixing Linus isn't enough.
>
> Have a look at this thread, especially how it is left (in my mind)
> unresolved after I did the legwork to refute Miller's assertion.
>
> <https://www.spinics.net/lists/netdev/msg342321.html>
>

I am totally with you on that one. I really do wish the LKML was an easier
community to work with.

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Linux 4.19-rc4 released, an apology, and a maintainership note

2018-09-17 Thread Dhaval Giani via talk
>
>
>>> Also on a personal note, you contacted me offlist to chastize me about
>>> some trivial comment I made about pulseaudio and at least one other person
>>> has named you pubically on this list for the same type of conduct.
>>>
>>>
>> I apologize for that.
>>
>
> Apology accepted and my own is offered up to you in return, for my own
> insensitivities in posting. Sometimes I forget the first rule of digial
> comment sensibility, wait and think before you hit send.
>

Thank you. I think we can all do be reminded of that from time to time!


>
>>
>>> Now you make this post as a maintainership note about why you leave
>>> hostile lists. What exactly do you define as hostile behaviour? I'd define
>>> it as being trolled offlist by someone who harvested my email and decided
>>> they had the right to contact me, just because they could.
>>>
>>> Systemd is a thing. Writing publically about a thing, even in criticism,
>>> even if you use words you can't say on TV, is so far removed from your own
>>> private ad hominem remarks offlist that I am raising your poor conduct, to
>>> remind you; just because you post a couple of true facts, that doesn't
>>> authenticate a third postulate you have formulated as some sort of
>>> gratification index.
>>>
>>>
>> I am just going to ignore the last bit. I bring up systemd, because it is
>> quite a bit my baby as well. I take every attack on it personally (rightly
>> or wrongly, and that is my problem, not _yours, as you have quite pointed
>> out later on in your email). Which quite brings to my point, you have folks
>> who are directly impacted by your words. Am I right in defending my baby?
>> Am I right in getting defensive about it? Am I right in not being able to
>> separate out the project from the person? These are all personal questions.
>>
>> All that matters is, everything people say, has an impact, and a result.
>> You might call it illogical (in your opinion), but it has happened. There
>> have been times where I felt I could participate in discussions and talk
>> about it.
>>
>> Spectre/Meltdown was one such. I talked about the importance of it, and
>> it was immediately shot down as corporate conspiracy. Of course, we are
>> still dealing with the fallout. What is my relation with this? For the last
>> many months, I have been part of the response force for my employer to deal
>> with the intel flaws. But feeling (note the word) attacked, doesn't make me
>> feel inclined to share. Certainly not my loss.
>>
>>  I'm not exactly sure what it is that you maintain
>>
>>
>> I don't actively maintain anything right now. I took time off for mental
>> health reasons. Part of it is physiological, but a lot of was exacerbated
>> by working in open source. That is a different story, and not the topic of
>> this email. If you want, ping me offlist, and I will send you a more
>> detailed email.
>>
>
> Stress is one of the most enduring problems in the modern corporste world.
> Sorry if I have added to your own at this time. I do appreciate the fact
> that it takes a particular kind of fortitude to continue to participate
> under such adverse conditions and I hope you understand my regret is
> sincere.
>

One of the things I would like to do some day is write down my thoughts on
this topic. (Probably not for sharing though). These days I manage a team
of open source developers, and a lot of my time is spent trying to look at
it from their point of view. "How this affect my career?" "How did my
working with person X affect my career?" (positively/negatively). There are
times they are unable to make progress, because we are all humans, and
communication is the hardest skill to learn, they view it as affecting
their career negatively. It is quite different from, just the black and
white of the technicalities.

I am pretty sure these problems have been already been solved elsewhere. I
am curious to see how and to what extent.

Dhaval


>
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Linux 4.19-rc4 released, an apology, and a maintainership note

2018-09-17 Thread Dhaval Giani via talk
On Mon, Sep 17, 2018 at 3:11 AM Russell Reiter  wrote:

> On Sun, Sep 16, 2018, 11:52 PM Dhaval Giani via talk 
> wrote:
>
>> https://lwn.net/Articles/764901/
>>
>> ...
>>
>> To tie this all back to the actual 4.19-rc4 release (no, really, this
>>> _is_ related!) I actually think that 4.19 is looking fairly good,
>>> things have gotten to the "calm" period of the release cycle, and I've
>>> talked to Greg to ask him if he'd mind finishing up 4.19 for me, so
>>> that I can take a break, and try to at least fix my own behavior.
>>
>> ...
>>
>> Jono Bacon's comments on it,
>>
>>
>> https://www.jonobacon.com/2018/09/16/linus-his-apology-and-why-we-should-support-him/
>>
>> 
>>
>> Another interesting article that I read over the past few days was a
>> Python keynote talk,
>> https://snarky.ca/setting-expectations-for-open-source-participation/
>>
>> 
>>
>> On a more personal note, I have seen "hostile" behavior on many mailing
>> lists, which has led me from withdrawing from participating on them.
>>
>> We tend to attack developers without thinking of the impact on them.
>>
>> This list is an example of attacks on systemd. While Lennart doesn't read
>> this list personally, I do know of the impact systemd criticism has had on
>> him. He has shared recordings of death threats because of systemd. I think,
>> we can all agree that, systemd, or pulseaudio did not make linux worse, at
>> least enough to justify death threats.
>>
>> They haven't even made it bad enough to justify the constant attacks on
>> the software.
>>
>> Remember, if you have a better idea, you have the _freedom_ to implement
>> it. You, however, do not have the freedom to expect them to drop what they
>> want to do, to fix your problems, and when they don't want to, be subject
>> to attacks from you.
>>
>> 
>>
>> I do hope, Linus taking some time off will make things better for him,
>> and by extension Linux.
>>
>
>
> The Poettering hit man story is four years old. It didn't stop him from
> his own rant, they are after all just words.
>
>
They are just words for you. But you ignore a phone call from an unknown
number. And then you listen to voicemail, and it a voicemail threatening to
kill you because of systemd, at that point in time, it has stopped being
mere words. Yes, 4 yrs old. Has it stopped having impact? No.


>
> https://www.google.ca/amp/s/www.zdnet.com/google-amp/article/lennart-poetterings-linus-torvalds-rant/
>
> "Open Source community is full of a**s, and I probably more than most
> others am one of their most favourite targets. I get hate mail for hacking
> on Open Source. People have started multiple 'petitions' on petition web
> sites, asking me to stop working (google for it). Recently, people started
> collecting Bitcoins to hire a hitman for me (this really happened!). Just
> the other day, some idiot posted a 'song' on YouTube, a creepy work, filled
> with expletives about me and suggestions of violence. People post websites
> about boycotting my projects, containing pretty personal attacks."
>
> Also on a personal note, you contacted me offlist to chastize me about
> some trivial comment I made about pulseaudio and at least one other person
> has named you pubically on this list for the same type of conduct.
>
>
I apologize for that.


> Now you make this post as a maintainership note about why you leave
> hostile lists. What exactly do you define as hostile behaviour? I'd define
> it as being trolled offlist by someone who harvested my email and decided
> they had the right to contact me, just because they could.
>
> Systemd is a thing. Writing publically about a thing, even in criticism,
> even if you use words you can't say on TV, is so far removed from your own
> private ad hominem remarks offlist that I am raising your poor conduct, to
> remind you; just because you post a couple of true facts, that doesn't
> authenticate a third postulate you have formulated as some sort of
> gratification index.
>
>
I am just going to ignore the last bit. I bring up systemd, because it is
quite a bit my baby as well. I take every attack on it personally (rightly
or wrongly, and that is my problem, not _yours, as you have quite pointed
out later on in your email). Which quite brings to my point, you have folks
who are directly impacted by your words. Am I right in defending my baby?
Am I right in getting defensive about it? Am I right in not being able to
separate out the project from the person? These are all personal questions.

All that matters is, everyt

[GTALUG] Linux 4.19-rc4 released, an apology, and a maintainership note

2018-09-16 Thread Dhaval Giani via talk
https://lwn.net/Articles/764901/

...

To tie this all back to the actual 4.19-rc4 release (no, really, this
> _is_ related!) I actually think that 4.19 is looking fairly good,
> things have gotten to the "calm" period of the release cycle, and I've
> talked to Greg to ask him if he'd mind finishing up 4.19 for me, so
> that I can take a break, and try to at least fix my own behavior.

...

Jono Bacon's comments on it,

https://www.jonobacon.com/2018/09/16/linus-his-apology-and-why-we-should-support-him/



Another interesting article that I read over the past few days was a Python
keynote talk,
https://snarky.ca/setting-expectations-for-open-source-participation/



On a more personal note, I have seen "hostile" behavior on many mailing
lists, which has led me from withdrawing from participating on them.

We tend to attack developers without thinking of the impact on them.

This list is an example of attacks on systemd. While Lennart doesn't read
this list personally, I do know of the impact systemd criticism has had on
him. He has shared recordings of death threats because of systemd. I think,
we can all agree that, systemd, or pulseaudio did not make linux worse, at
least enough to justify death threats.

They haven't even made it bad enough to justify the constant attacks on the
software.

Remember, if you have a better idea, you have the _freedom_ to implement
it. You, however, do not have the freedom to expect them to drop what they
want to do, to fix your problems, and when they don't want to, be subject
to attacks from you.



I do hope, Linus taking some time off will make things better for him, and
by extension Linux.

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Alternative to Rogers

2018-04-03 Thread Dhaval Giani via talk
On Tue, Apr 3, 2018 at 8:09 AM Dave Cramer via talk  wrote:

> So one more time they put the prices up.
>
> This time the Roam Like at Home. now max of $90. Started at 50, that was
> acceptable. then 60, now 90.
>
> So what options are there for
>
> 1) internet. 150M plans
> 2) US SIM or even a US plan
>

If you have a google phone then you could try google fi. It is 20usd a
month, if you are on Wi-Fi, calling is free to us and Canada otherwise it
is .20 a minute (while roaming). 1 gig of data is $10 but you get back what
you didn’t use. Having said that it is google run, so would you trust them
that much?

Dhaval



>
> Dave Cramer
> ---
> Talk Mailing List
> talk@gtalug.org
> https://gtalug.org/mailman/listinfo/talk
>
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] python sweetness — The mysterious case of the Linux Page Table

2018-01-03 Thread Dhaval Giani via talk
On Wed, Jan 3, 2018 at 11:53 PM John Sellens via talk 
wrote:

> One could assert that the days of time sharing systems are largely over,
> at least on production systems that people care about.
>
> And I think it's fair to say that it has been good practice for quite
> some time to not allow random binaries to run on systems you care about.
>
> I have no idea whether hypervisors (like xen or esxi) are vulnerable.
> But the same guidelines can be applied to VMs running on hypervisors.
>

Xen and kvm are both affected.


> I wonder how exploitable this problem really is?
>

Meltdown already has some exploits around that I am seeing. I also believe
there is some poc code out there to exploit it. One of which I believe is
executing JavaScript in your web browser to get kernel space data.

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] python sweetness — The mysterious case of the Linux Page Table

2018-01-03 Thread Dhaval Giani via talk
Russell

On Wed, Jan 3, 2018 at 11:59 PM Russell Reiter  wrote:

>
>
> On January 3, 2018 10:56:30 PM EST, Dhaval Giani 
> wrote:
> >
> https://googleprojectzero.blogspot.ca/2018/01/reading-privileged-memory-with-side.html
> >gives the gory details
> >
> >At this point, I cannot stress on how important it is to update your
> >systems as soon as your distribution ships them. I am hoping this
> >remains to be a once in a lifetime event.
>
> I admire your optimism. To me it looks like this is a kind of example of
> feeping creaturisim in hypervisor's; not necessarily an easy patch.
>

I am unsure what you are implying. This is a hardware issue which has been
fixed in software. There are exploits out already that I am seeing able to
run through your web browser. This is serious stuff. Also unsure what this
has to do with hypervisors apart from them also needing to mitigate this
exploit.


>
> The idea of the necessity of some sort of kernel isolation has been around
> for quite a while. In part as a response to the ease with which userland
> interpreters can polute kernelspace.
>
> https://lwn.net/Articles/39283/
>
> I've read that some of the proposed solutions could add as much as a 30%
> operational overhead. Not much of an issue for average home users but for
> enterprise this could be a real game changer.
>

The 30% overhead is for a pathological case. A 5-10% overhead is more
likely. And do you honestly think that upstream is not going to work on
getting that overhead down?

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] python sweetness — The mysterious case of the Linux Page Table

2018-01-03 Thread Dhaval Giani via talk
https://googleprojectzero.blogspot.ca/2018/01/reading-privileged-memory-with-side.html
gives the gory details

At this point, I cannot stress on how important it is to update your
systems as soon as your distribution ships them. I am hoping this
remains to be a once in a lifetime event.

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Flatpak: Anyone with Experience or Opinions on It?

2017-11-03 Thread Dhaval Giani via talk
On Fri, Nov 3, 2017 at 1:04 PM, John Sellens via talk  wrote:
> I've long found it disappointing the way shared libraries are dealt with
> in linux and other OSs.
>
> To me, the obvious solutions is to install every library into a directory
> named for the version, or name the library itself with a version number.
> Then, if you wish, a default version can be chosen and linked/symlinked
> into the default directory.
>
> That way, a program that wants a particular version gives the
> compiler/linker the appropriate search path to find the preferred version.
>

How do you ensure security updates happen everywhere, or that you are
not linking to an insecure version? What about old software which is
no longer maintained? Also work is not duplicated?

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Flatpak: Anyone with Experience or Opinions on It?

2017-11-03 Thread Dhaval Giani via talk
> As an example of the role of distros, consider the Linux Kernel.  It
> used to be common for folks to take the Linus kernel and build it on
> their own machine and use it in place of their distro's kernel.  It
> wasn't too hard.  Linus went to some trouble to make sure a release
> was clean.  I infer that things have changed.  All distros take a raw
> release and fix it up before shipping it.  And you want those fixes.
> It's not impossible to build a Linus kernel and use it but it is
> probably not worthwhile.

Define: all distros :-). Fedora keeps updating to the latest mainline
(stable) and is quite aggressive in its upgrade schedule. RHEL, SLES
(and other enterprise distros) not so much. RHEL and SLES have
different stability models (which require them to backport a lot of
patches). Canonical sticks to one release for its entire release life
(which has them somewhere in between). The kernel is actually a really
terrible example of flatpaks because it doesn't have dependencies like
other packages.

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Adobe Reader Alternatives for Linux

2017-10-12 Thread Dhaval Giani via talk
On Wed, Oct 11, 2017 at 6:26 PM, Brian Carlile via talk  wrote:
> Anybody else tried "Master PDF Editor" (http://code-industry.net)? I ran in
> to the same government document issue with another pdfnand wondered if an
> editor rather than a reader might be the solution. This one seems to work on
> the pdf under discussion, allowing filling and saving ... at least for me
> with Linux Mint 18.2 Cinnamon
>

I gave it a run, and wouldn't use it for this form. For one, it prints
the buttons as well, whereas Adobe Reader DC doesn't. So you would
still be in the situation of finding a reader which can print it
properly. I finally remembered that my work laptop also has windows
:D. (Oh boy, the number of policy violations I must have hit while
rebooting ;-) ) and could get access to Adobe through that.

Thanks!
Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Adobe Reader Alternatives for Linux

2017-10-11 Thread Dhaval Giani via talk
On Wed, Oct 11, 2017 at 10:16 AM, Myles Braithwaite  <m...@mylesb.ca> wrote:
> Dhaval Giani via talk wrote:
>> However the government of Canada (in its infinite wisdom) has mandated
>> that to open and fill their forms, one use Adobe Reader. (As an
>> example see http://www.cic.gc.ca/english/pdf/kits/citizen/CIT0002E-2.pdf
>> ).
>>
>> Alternatives?
>
> Not sure if you tried this yet but Adobe released a version of Acrobat
> Reader for Linux in 2013 you can still download off their FTP server:
> <ftp://ftp.adobe.com/pub/adobe/reader/unix/9.x/9.5.5/enu/>.

Hi Myles,

I thought about it. But 4 yr old software, from a company that has a
history of security issues? :-). Not my first choice.

Thanks!
Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


[GTALUG] Adobe Reader Alternatives for Linux

2017-10-11 Thread Dhaval Giani via talk
Hi folks,

Yes, I am aware that there are many applications out there that can read pdfs.

However the government of Canada (in its infinite wisdom) has mandated
that to open and fill their forms, one use Adobe Reader. (As an
example see http://www.cic.gc.ca/english/pdf/kits/citizen/CIT0002E-2.pdf
).

Alternatives?

Thanks!
Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] From BTRFS to what?

2017-09-05 Thread Dhaval Giani via talk
Hi Alvin

>
> That is not even close to a real characterization of the conversation.
> The point has been that losing a major distribution, and RH is a major
> distribution,  just takes away from the momentum that a project may have.
> Take a look at Xen and its uptake outside Citrix once RH moved to KVM.
>

As I have mentioned countless times in this thread. Red Hat is not a
major contributor to btrfs (and hasn't been for a while). If you want
a big adoptee of btrfs, look at facebook.

Please understand, by constantly going back to Red Hat, you are
ensuring Open Source and the Linux Kernel get looked as a single
company project. From what I can see on lwn, red hat hasn't even been
a majority contributor to the kernel for a while.  So, please stop
spreading this bit that just because red hat has pulled support away
from a project, it will die. The project will go away only when there
are superior options.

Thanks!
Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] From BTRFS to what?

2017-09-04 Thread Dhaval Giani via talk
On Mon, Sep 4, 2017 at 11:49 AM, D. Hugh Redelmeier via talk
<talk@gtalug.org> wrote:
> | From: Dhaval Giani via talk <talk@gtalug.org>
>
> | Redhat was never a major contributor to btrfs. The folks who are on btrfs
> | like it and will continue fund its development. We might see a btrfs v2
> | similar to ext3 and ext4. But only time will tell. Please let's not equate
> | red hat with upstream kernel development. There are a lot of us who are
> | unrelated to red hat doing it as well.
>
> I agree with all that.  However...
>
> I use RedHat distros.  I use RedHat as my quality control.  Generally
> I have to seriously disagree with them to go to the bother of using
> something that they intentionally don't support.
>

You use Red Hat as your quality control. Lot of us do not. (Fedora is
a different issue), but the red hat kernel is a beast. I have
complaints against it, but that is for another forum. However, my
point is, it is not necessarily quality control. What gets red hat its
customers is it is support contracts, and the fact that it hires mores
of the upstream developers.

> I've only used BTRFS by accident (I installed Fedora and somehow got
> it).  It was not a problem.  So I have no actual technical complaint
> about BTRFS.
>
> Here are the strikes against it:
>
> - it has taken way too long to be technically mature (at least I've
>   inferred this)
>

How long do you think it took for it to be technically mature? How
long did say, xfs take, or ext4 take in comparison? Also, how much of
a radical change was btrfs? btrfs is probably not the answer, and
there will be other filesystems that will be better, but it is a
pioneering filesystem in linux land.
'

> - long time-to-develop suggests complexity.  Complexity is a really
>   bad thing if you want reliability.
>

Accepted.

> - I'm *very* conservative about filesystems.  When they go wrong they
>   can cause long-term consequences.
>

Almost everyone is, which is why btrfs adoption has not happened.
People trust their xfses and like, and don't want to move unless there
is a real compelling reason.

> - my distros of choice no longer support BTRFS.  That's much more
>   negative than "don't yet support".  It's a really big deal when
>   RHEL drops something, especially in a point release.
>

Again, the emphasis being *your*.

> - BTRFS looks to have a big fat niche and yet it has failed to fill
>   it.  Perhaps it has even blocked others from entering that niche.
>
> I'd love BTRFS to be developed and prove the nay-sayers (like me)
> wrong.  It does a bunch of things we could really use.
>

And as I have repeatedly said in this thread. Btrfs development is
*NOT* stopping. All that is stopping is Red Hat's support in RHEL.
While it might be a big deal for some (as you have rightly pointed
out), upstream development will continue to happen, fixes will keep
coming in, until something new and shiny comes in. But let's not say,
"Red Hat no longer supports feature X in the kernel, so it is game
over". That is a disservice to a lot of us who do this, and are not
employed by Red Hat. The linux kernel is a community effort, let's not
give Red Hat all the credit.

Thanks!
Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] From BTRFS to what?

2017-09-04 Thread Dhaval Giani via talk
>
>
> I was not trying to equate RH with BTRFS development but pointing out that
> when a major distribution provider decides to drop a project that they once
> included its a big hit for the project.
>

And as I mentioned, Red Hat was never a major contributor to btrfs.
AFAIK, the maintainer of btrfs still contributes and maintains btrfs
(and fwiw, he is almost local to us folks from the GTA). The other
folks who contribute to btrfs still do. Bugs still get reported and
fixed. There may not be too many new features coming, but how many
mature filesystems have new features come in? This bit about btrfs
being deprecated sounds like FUD to me, when at least no one upstream
thinks that's the case.

Again, RH not supporting btrfs officially just tells us that they did
not get that many customer requests to justify *their* investment in
it. Not that it will be deprecated by the upstream community (which is
what you should care about). Not that it will be a big hit to the
project.

Thanks!
Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] From BTRFS to what?

2017-09-03 Thread Dhaval Giani via talk
On Sun, Sep 3, 2017 at 9:02 PM Alvin Starr via talk <talk@gtalug.org> wrote:

> On 09/03/2017 02:53 PM, Dhaval Giani via talk wrote:
>
>
> On Sun, Sep 3, 2017 at 2:13 PM William Park via talk <talk@gtalug.org>
> wrote:
>
>> On Sun, Sep 03, 2017 at 05:52:12PM +, Dhaval Giani wrote:
>> > On Sun, Sep 3, 2017 at 1:41 PM William Park via talk <talk@gtalug.org>
>> > wrote:
>> > > Now, I read (it's an old news, though) that BTRFS is being
>> "deprecated"
>> > > by Redhat, and presumably others will follow.
>> >
>> > Where have you read this news? As far as I know btrfs is actively being
>> > developed and no one is stopping development.
>>
>> https://www.theregister.co.uk/2017/08/16/red_hat_banishes_btrfs_from_rhel/
>>
>>
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html
>>
>>
>> https://www.phoronix.com/scan.php?page=news_item=Red-Hat-Deprecates-Btrfs-Again
>
>
> Still doesn't say that upstream development has stopped.
>
> Dhaval
>
>
> True enough.
> But with Redhat voting with their feet it will make the uptake of BTRFS
> much slower if at all.
>

Redhat was never a major contributor to btrfs. The folks who are on btrfs
like it and will continue fund its development. We might see a btrfs v2
similar to ext3 and ext4. But only time will tell. Please let's not equate
red hat with upstream kernel development. There are a lot of us who are
unrelated to red hat doing it as well.

Thanks
Dhaval



> Remember Reiserfs? I was a great filesystem at least for my use. Much more
> reliable then the equivalent ext systems but non-technology related issues
> killed it.
>
> There may be an open GPL version of ZFS(Open ZFS).
> There is bcachefs.
>
>
>
> --
> Alvin Starr   ||   voice: (416)585-9971x690
> Interlink Connectivity||   fax:   (416)585-9974al...@iplink.net   
>||
>
>
> ---
> Talk Mailing List
> talk@gtalug.org
> https://gtalug.org/mailman/listinfo/talk
>
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] From BTRFS to what?

2017-09-03 Thread Dhaval Giani via talk
On Sun, Sep 3, 2017 at 2:13 PM William Park via talk 
wrote:

> On Sun, Sep 03, 2017 at 05:52:12PM +, Dhaval Giani wrote:
> > On Sun, Sep 3, 2017 at 1:41 PM William Park via talk 
> > wrote:
> > > Now, I read (it's an old news, though) that BTRFS is being "deprecated"
> > > by Redhat, and presumably others will follow.
> >
> > Where have you read this news? As far as I know btrfs is actively being
> > developed and no one is stopping development.
>
> https://www.theregister.co.uk/2017/08/16/red_hat_banishes_btrfs_from_rhel/
>
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html
>
>
> https://www.phoronix.com/scan.php?page=news_item=Red-Hat-Deprecates-Btrfs-Again


Still doesn't say that upstream development has stopped.

Dhaval



> --
> William Park 
> ---
> Talk Mailing List
> talk@gtalug.org
> https://gtalug.org/mailman/listinfo/talk
>
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Dinner Tonight

2017-07-11 Thread Dhaval Giani via talk
Hi David,

I think we are trying out Bangkok Garden.

Thanks
Dhaval

On Tue, Jul 11, 2017 at 3:57 PM, David Collier-Brown via talk
<talk@gtalug.org> wrote:
> OK, I'll try those in order...
>
> --dave
>
>
> On 11/07/17 11:35 AM, Dhaval Giani via talk wrote:
>>
>> Hi Folks,
>>
>> Thoughts for dinner? I am thinking thai.
>>
>> I see
>> Thai on Yonge
>> Basil Box
>>
>> Suggestions?
>>
>> Thanks!
>> Dhaval
>> ---
>> Talk Mailing List
>> talk@gtalug.org
>> https://gtalug.org/mailman/listinfo/talk
>
>
>
> --
> David Collier-Brown, | Always do right. This will gratify
> System Programmer and Author | some people and astonish the rest
> dav...@spamcop.net   |  -- Mark Twain
>
>
> ---
> Talk Mailing List
> talk@gtalug.org
> https://gtalug.org/mailman/listinfo/talk
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Dinner Tonight

2017-07-11 Thread Dhaval Giani via talk
> Bangkok Garden, 18 Elm street

Sounds interesting to me.

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


[GTALUG] Dinner Tonight

2017-07-11 Thread Dhaval Giani via talk
Hi Folks,

Thoughts for dinner? I am thinking thai.

I see
Thai on Yonge
Basil Box

Suggestions?

Thanks!
Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] git - push and pull attached to different remotes?

2017-06-05 Thread Dhaval Giani via talk
On Mon, Jun 5, 2017 at 6:47 PM, Giles Orr via talk  wrote:

> This isn't strictly a Linux question, but this list is a great
> knowledge base and I know a lot of you use git.  Usually on Linux.
> :-)
>
> I've written a Python program that checks all of your repositories to
> see if they're up-to-date with your remotes.  But given the
> flexibility of git - and the output of 'git remote show origin' which
> shows separate URLs for "Fetch" and "Push" - it's occurred to me that
> it's probably NOT safe to assume that the Fetch and Push URLs are the
> same.  But ... does anyone actually have different Fetch and Push
> URLs?  Why would you do this?
>
>
I do. On some machines, I don't have ssh-agent setup because I can't set it
up :-). In that case, my push is to ssh and my fetch is from git://. (I
hope you all use passcodes with your ssh keys :-) )

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Any Debian Developers here can help me sign my GPG key?

2017-06-05 Thread Dhaval Giani via talk
Hi Antonio,



On Mon, Jun 5, 2017 at 1:50 PM, Antonio Sun via talk 
wrote:

> Good to know and thanks for replying, Lennart.
>
> Would you ask around if there are any Debian Developer
> around uwaterloo please? (since I saw your are replying from
> csclub.uwaterloo.ca address), because the THUG group,
> http://www.nongnu.org/thug/, was organized by a bunch of Debian Developer
> in uwaterloo.
>
>>
>>
Might I suggest https://db.debian.org/ ?

Thanks!
Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Can the speakers from last night post their names?

2017-03-15 Thread Dhaval Giani via talk
On Wed, Mar 15, 2017 at 8:44 AM David Collier-Brown via talk <
talk@gtalug.org> wrote:

> I wanted to update the page (and have added my talk), but I also wanted to
> know who spoke about being a maintainer: I was his opposite number at Sun,
> looking after libraries, APIs and educating folks about resource
> management.  The latter was *hard* to explain (;-))
>

Hi David,

That would be me. Talk was titled, "what I learned as a maintainer " or
something similar :).

Thanks
Dhaval

--dave
>
> --
> David Collier-Brown, | Always do right. This will gratify
> System Programmer and Author | some people and astonish the 
> restdav...@spamcop.net   |  -- Mark Twain
>
> ---
> Talk Mailing List
> talk@gtalug.org
> https://gtalug.org/mailman/listinfo/talk
>
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Dinner for the 14th?

2017-02-13 Thread Dhaval Giani via talk
On Mon, Feb 13, 2017 at 4:02 PM, Christopher Browne via talk
 wrote:
> On 11 February 2017 at 16:55, Scott Sullivan via talk  wrote:
>> Let's get this ball rolling.
>>
>> My personal criteria is adequate seating and low noise.
>>
>> These two stand out as reasonable, from my memory.
>>
>> Thai on Yonge
>>
>> Address: second floor, 370 Yonge Street (South of Gerrard St.)
>>
>> Basil Box
>>
>> Address: 351 Yonge St. (part of Ryerson SLC building)
>>
>> Any leanings towards on in particular folks?
>
> Both were pretty OK; I'd be fine with either.
>
> We of course need a choice; I'll suggest Thai on Yonge.
>

I haven't been to either, and looked them up, and Basil Box seems more
interesting to me :-).

Thanks!
Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Crashes

2017-01-31 Thread Dhaval Giani via talk
On Tue, Jan 31, 2017 at 10:28 AM Giles Orr via talk  wrote:

> On 31 January 2017 at 10:03, Alvin Starr via talk  wrote:
> > On 01/31/2017 09:07 AM, Giles Orr via talk wrote:
> >> My primary machine is crashing with increasing frequency.  The
> >> commonest error I'm seeing in the log looks like this:
> >>
> >> Jan 29 18:29:39 toshi7 kernel: nouveau :01:00.0: DRM: suspending
> >> kernel object tree...
> >> Jan 29 18:30:00 toshi7 kernel: NMI watchdog: BUG: soft lockup - CPU#3
> >> stuck for 23s! [kscreenlocker_g:19647]
> >> Jan 29 18:30:00 toshi7 kernel: Modules linked in: fuse uas usb_storage
> >> rfcomm ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set
> >> nfnetlink ebtable_broute bridge stp llc ebtable_nat ip6table_nat
> >> nf_conntrack ...
> >>
> >> I realize that I'm probably not giving enough information, but pasting
> >> large chunks of log files would be just as counterproductive in its
> >> own way.  I've seen this one A LOT - and sometimes I get it and the
> >> machine goes hours (but not days) before crashing.  So ... is
> >> kscreenlocker likely to be the problem here?  When I searched for "BUG
> >> soft lockup CPU stuck for" on Google, the top result had exactly the
> >> same number of seconds, and said that replacing the power supply fixed
> >> the problem.  Which is a step I'd probably be willing to take, but
> >> this isn't a desktop, it's a laptop.  So I'd want to be very sure as
> >> the power supply is unique to this machine (if it's available at all)
> >> and probably quite expensive.
> >>
> >> The processor:
> >>
> >> Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz (4594 bogomips)
> >> current speed: 1274MHz, 4 cores, 8 threads
> >>
> >> While it's not a current gen processor, this is still a good machine
> >> and I'd rather fix it than toss it.
> >>
> >> Got an immediate crash this morning, and to my surprise the error was
> >> very different:
> >>
> >> Jan 31 07:56:35 toshi7 kernel: [ cut here ]
> >> Jan 31 07:56:35 toshi7 kernel: kernel BUG at lib/radix-tree.c:769!
> >> Jan 31 07:56:35 toshi7 kernel: invalid opcode:  [#1] SMP
> >> Jan 31 07:56:35 toshi7 kernel: Modules linked in: uas usb_storage
> >> rfcomm ip6t_rpfilter ip6t_REJECT nf_reject
> >> _ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge
> >> stp llc ip6table_nat nf_conntrack_ipv6 ...
> >>
> >> Finally, I'm also getting this periodically:
> >>
> >> Jan 28 08:49:52 toshi7 kernel: CPU2: Core temperature above threshold,
> >> cpu clock throttled (total events = 1
> >> )
> >> Jan 28 08:49:52 toshi7 kernel: CPU6: Core temperature above threshold,
> >> cpu clock throttled (total events = 1)
> > [snip]
> >> Jan 28 08:49:52 toshi7 kernel: CPU0: Package temperature/speed normal
> >> Jan 28 08:49:52 toshi7 kernel: CPU2: Package temperature/speed normal
> >> Jan 28 08:49:52 toshi7 kernel: CPU6: Package temperature/speed normal
> >>
> >> This suggests that it's overheating, throttling, and recovering pretty
> >> much instantaneously: my thought is that it's probably not a problem,
> >> but I thought I should check.
> >>
> >> How should I proceed from here:
> >> - the processor is going funny, replace it
> >> - junk the laptop, it's toast
> >> - debug further (how?)
> >> - replace the power supply
> >> - uninstall kscreenlocker and see what happens
> >>
> >
> > If the CPU is going over temp then it could start acting unpredictably.
> >
> > If you have lm_sensors installed then it would be worthwhile checking
> > the temp of the CPU during normal operation.
> > I would also check the fans because most fans out there are
> > "inexpensive" and will start to cease up over time slowing down till
> > things start getting hot.
> > Another thing that has bitten me in the past was pushing a computer with
> > a side vent up against a wall causing the still good fans from working
> > almost at all.
> >
> > Another thing that will cause random problems is memory so if the
> > cooling is not the issue then try running a memory test.
> > Unless you have ECC and there are no errors being logged.
>
> I should add that I ran memtest86(+?) for a couple hours a month ago,
> and it came up error-free.  And I ran the smartctl long test on the
> hard drive quite recently, again without error.  I should run the
> memory test again (and possibly even the HD one), but it makes me
> think that these aren't the problem.  I think the fans are functioning
> okay, but that's worth looking at and I'll get lmsensors installed
> again.
>

Hi,

A good starting point would be knowing what you are running. Also updating
to the latest packages for you distro as it might already be fixed.

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] Question

2017-01-12 Thread Dhaval Giani via talk
Hi,

On Thu, Jan 12, 2017 at 2:24 PM, o1bigtenor via talk  wrote:
> On Thu, Jan 12, 2017 at 12:28 PM, Jason Shaw via talk  wrote:
>> I feel obligated to point out freshbooks.com as Accounting as a Service
>> based here in Toronto.  I do work there, so I'm a touch biased, but it
>> provides multiple users, mobile apps (android and iOS), as well as browser
>> based ui.
>>
> Sorry - - - lots of companies/people think the web is secure. I'm not one of
> them - - - - especially when it comes to financial data.
>

I feel obligated to point out here that it is more often the case that
a cloud provider is more secure than a standalone solution. If only
because they can afford to spend more on hiring people to work on
security full time.

Thanks!
Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk


Re: [GTALUG] curious... Linux vs BSD ?

2016-09-30 Thread Dhaval Giani via talk
On Fri, Sep 30, 2016 at 10:47 AM, o1bigtenor via talk 
wrote:

> On Fri, Sep 30, 2016 at 9:28 AM, Alvin Starr via talk 
> wrote:
> > On 09/29/2016 11:52 PM, Peter King via talk wrote:
> >
> > On Thu, Sep 29, 2016 at 10:45:09AM -0400, Lennart Sorensen via talk
> wrote:
> snip
> >
> > Not sure why people have a hate on for systemd.
> > It is a pain to learn a new way to manage your systems but it solves a
> > number of problems and gets systems into a usable state faster in the
> face
> > of startup problems.
> > I curse systemd on a daily basis because my fingers know init but quite
> > frankly having to wait 30 minutes for a system to boot up with init
> because
> > some network connections need to time out is a major pain when its a
> > critical system and the phones are all lit up.
> > systemd removes the single threaded-ness of init and also provides a much
> > better mechanism for dependency resolution.
> snip
>
> Well - - - I can tell you why I find systemd a royal PITA. Systemd wants
> to be
> everything to everybody. That's astronomically difficult to do and what is
> in
> place today doesn't work half as well as it purports to. I have run
> into some of
> the issues which have resulted in a lot of hair pulling (hard when
> there's little
> left) in the process of resolving issues.
>
>
I am curious to know what some of these issues are. (Feel free to privately
email me if you feel more comfortable with that). Systemd is not everything
to everybody. It is a number of distinct binaries (doing that one thing at
a time bit). As systemd keeps evolving, they hit limits of existing tools,
and instead of waiting for them to catch up, they just rewrite and move on.
Maybe we might actually end up with a plumbing layer unified across all
distros.


> I think that the original *nix thinking of doing one thing (at a time)
> and doing
> it well or better is my preferred solution. Part of the problem is
> that, even in
> linux, there are too many silos being built and not enough communication.
>
> I wonder if that is because most of the code writers are not really human
> communicators rather they are far better machine communicators?
> What say you?
>
>
I feel that is unfair.

Dhaval
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk