A capabilities system like pledge could be a way to safer use _existing_ packages. However, I think that it's not a very nice way to continue. Every application will end up doing its own capability pledging, and mistakes will be made. A lot.
Another approach could be to use an effect system like PureScript does. The main problem with Node.js packages is that any function you use can execute arbitrary code (such as wiping systems with an IP that is from the Russian region). Having an effect system in place the library author has no other means than to come forward with the side-effect, or code won't compile.
> "If I can't search the file for this variable and find it easily, it's a bad name"
Like parent mentions, this is about scoping. My rule about short variables is that I have to see their _full_ use (including declaration) in only a few lines on the screen.
Personally I prefer single letter variables especially in lambdas for consistency (x, y, z).
From the thread is becomes painfully clear how horrible Actalis is set up to act as a CA. Instead it seems they chose to break the BR by default. Almost 5 months to reissue a little over 250k certificates is not what you may expect from a CA that a major browser should trust.
The argument that there might be some end-users unable to renew their prescription seems mostly used to gain sympathy. Also this will most probably not be “a large swath of internet users”.
I do hope Actalis step up their game and regain some trust. Or it may become the next symantec.
There are various ways. One would be to use standard imap and decrypt the message on the client. Their bridge sort of does that but with proprietary protocol.
Either way, that has absolutely nothing to do with the security issues of html email. Eg phishing and tracking still works when you decrypt the message and open it.
> I constantly need to spend mental energy on remembering which is the Ok and which is the Error
Right is actually a synonym for Ok.. besides, Either is useful for _much_ more than error handling. That is exactly why I dislike Error for the left side; often it's just not an error.
> reason the Linux Community don't want this sort of thing is that, frankly, they just hate stability
And yet I fearlessly upgrade my Linux system at any time. With OSX you first have to check if the software you use is at all compatible, especially if you use proprietary software..
> ELFs still don't even have an accepted embedded icon standard FFS
Also Apple does not embed icons in their binaries. Their app bundles are not binaries, they are a directory structure. The icon is just another file, just like the _actual_ executable(s).
> you could publish a binary containing native versions for all existing architectures
This sort of ignores the hardest part of shipping binaries; linked libraries. Dynamic linking everything is simply not always feasible. Not to mention libc.
Also I don't really understand why anyone on Linux would want this. The fact that I can recompile all of the software I use, is a really important feature to me and not a distribution problem. I can see why Apple wanted this to simplify distribution via their Appstore, but IMO that's mostly to work-around their specific distribution problems. I don't see any of those problems on Linux.
That _long_ list is limited to the "basic level" telemetry data and does not include e.g. automatic sample documents that Defender sends by default (those include you actual documents).
Microsoft proves over and over again that they are not trust worthy. I agree you shouldn't be using their OS, but sadly many people don't consider this a choice since it comes pre-installed on most PCs.
Since it's hardware sold by Apple I would assume that Apple figures that out with NVIDIA and collaborates. Apparently I'm wrong and Apple just doesn't give a crap as long as they can sell new products.
For a hobby computer it can be interesting to write your own driver. For a professional laptop not so much :)
> Can you just not write graphics drivers for macOS?
So this is seriously what you suggest owners of an older MBP (official Apple hardware, just over 4 years old) to do?
Since both Apple's drivers and NVidia's drivers are completely closed source, I'd say it's hardly possible to write a working driver (w/ hardware acceleration) for it.
Owner of a late 2013 15" MBP here. I never been eager to upgrade to new mac version too.
> Some time ago I was forced to upgrade to Sierra
Until about a month ago I ran Sierra - which worked fine and in 2 years didn't crash my mpb once.
Then I had to compile a few ios apps for work, and since xcode was outdated on Sierra, I had to upgrade to High Sierra. High Sierra kept crashing on me. Several coworkers also had this experience and suggested to upgrade to Mojave.
Meanwhile Apple also kept pushing to upgrade to Mojave via an os notification they showed a few times a day. So I sadly ran the "upgrade" to find out the system was much less stable than before. No I see why. Sadly my GFX-750 isn't supported.
For me this is the end of the line on macs. Newer MBPs have broken keyboard that Apple refuses to fix, and are really expensive to the old hardware they come with. And apparently you cannot even expect a >$3500 MBP to outlive 5 years because Apple breaks it with their software patches.
I'll have to buy a new laptop because I cannot even connect a proper external monitor anymore. Obviously it won't apple product. I'm thinking to go System76.
Another approach could be to use an effect system like PureScript does. The main problem with Node.js packages is that any function you use can execute arbitrary code (such as wiping systems with an IP that is from the Russian region). Having an effect system in place the library author has no other means than to come forward with the side-effect, or code won't compile.