I’d just like to interject for a moment. What you’re refering to as Linux, is in fact, GNU/Linux, or as I’ve recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.
Many computer users run a modified version of the GNU system every day, without realizing it. Through a peculiar turn of events, the version of GNU which is widely used today is often called Linux, and many of its users are not aware that it is basically the GNU system, developed by the GNU Project.
There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine’s resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Linux is normally used in combination with the GNU operating system: the whole system is basically GNU with Linux added, or GNU/Linux. All the so-called Linux distributions are really distributions of GNU/Linux!
So a Yubikey is not an electronic device that you need to carry?
iCloud Passwords don't run on an iPhone that is an electronic device that you need to carry?
Those electronic devices that you mention don't each store the keys in a proprietary format and you can't access them without the vendor's cooperation - i.e. vendor lock in?
>Those electronic devices that you mention don't each store the keys in a proprietary format and you can't access them without the vendor's cooperation - i.e. vendor lock in?
Passkey portability is being worked on. Here is the draft of the open standard:
No, the previous commenter is saying that you cannot trust the identity provided in commits period. This has nothing to do with trusting employees, rather placing trust in the identity in commit.
This is true in general internet, but workplaces are normally more high-trust. If one needs to guard themselves against hacking by their co-worker, they have less time and energy to do actual work.
So a fiction character is maaybe OK, as long as it is clearly fictional name and no one else in the company does that; but other stuff, like actually impersonating other co-workers would be very bad, and should eventually leave to firing.
It is the most secure browser. The lifetime of these kinds of bugs is generally a few weeks to perhaps 2 months. With a high churn codebase, these things just happen. There is a lot of ongoing work to mitigate the impact of renderer bugs, such as the V8 heap sandbox.
It can also be that AVP is an “emergent” product while they work on the parts for something larger. I would imagine a lot of the “harder” parts for AVP line up closely with whatever car Apple is attempting to build.
While Apple’s R&D budget can rival some small nations’ GDP, I think it will be exceedingly difficult for Apple to continue to pour resources into these project amid the apparent flop of AVP
Making a reliable OS from the ground up takes a lot of work from a lot of really skilled people. I don't think people give ReactOS enough credit.
It seems a lot of people look at the success of Linux and *BSD and assume that it's easy once people put their heads together, but what they're missing is:
A. Way more people had direct experience with Unix kernels by the early 1990s due to things like source available licensing and Lions' annotated Unix V6 source code being used as a university textbook since the late 70s. In the case of BSD, the code was mostly written already, they just had to get through the AT&T lawsuit and then remove the 6ish files that were deemed to be AT&T's IP.
B. Specifically for Linux, the project got a lot of financial and manpower support from big established companies like IBM and Oracle once it became clear that Linux could be a commercial Unix killer.
ReactOS doesn't get any of this. While there have been source code leaks, Microsoft remains very secretive about NT's internals and protective of its source code. Unlike with Unix, there's no NT-family of operating systems for people to draw knowledge from. There's NT and there's OpenVMS as a sort of distant cousin, neither of which are open source.
For what it's worth, I do think that ReactOS's goals are orthogonal to what people really want, which is the ability to run Windows software without needing to deal with Microsoft. You really don't need the NT kernel in order to do that, you just need a robust userland compatibility layer. I think this is why Wine has been so much more successful (especially now with Proton and SteamOS) than ReactOS.
I still dream to one day have an OSS Windows replacement that's like a Windows 7/XP/2000 desktop but with modern kernel features, APIs, and security patches. But I think the more likely future is compatibility layers for gamers and the continuing death of desktop computers for anyone who isn't an enterprise or enthusiast.
We're so far behind from having alternative OSes that are able to run software that's based on Win APIs that any compromise seems reasonable. Essentially, all we have at present is monopolistic, spying, ad-dropping Microsoft or nothing, so any alternative has to be better.
Linux with Wine is fine in its own right and I use the combination but it isn't a true substitute for the ordinary user who has been used to using Windows for decades. Witness the pitifully small numbers of Linux desktop installations compared with Windows and the even smaller number of Linux users who use Wine. (Yes, I know Linux's desktop share has increase recently, and that's a good thing, but the numbers are still trivial.)
Seems to me pragmatism has to reign in the way that many users install Nvidia drivers on Linux. Granted, it's not the ideal for open source but the compromise is better than the alternatives.
What would a NT-compatable kernel get you that wine doesn't already have, other than the drivers? And my point is that having that is cool, but the drivers aren't open source so a lot of potential volunteers won't care anyways because of that.
Because OSS is a thankless job and _free volunteer_ work. The more niche something is such as Windows kernel clone development, the ridiculously smaller pool of potential contributors that may even want to contribute _their personal free time_ to spend on it.
And I come from the perspective of other large niche OSS projects.
"Because OSS is a thankless job and _free volunteer_ work. "
Agreed, it's why I've advocated a halfway 'house' to overcome the problem and pay for the project's development.
It goes something like this (but no doubt there are many suitable variations): create a nonprofit cooperative organization/society that is revenue neutral to develop programs and pay developers a reasonable wage. Employment could be flexible, the organization could employ both full-time and part-time developers (this would help those who've a keen interest in the project but whose principal job is too valuable to let go etc.)
In effect, this software has a cost but it would be very much cheaper than products from Microsoft, Adobe, etc. Also, licensing would be less restrictive—say make the product still cheaper or even free if one compiles the code oneself. There are ways of releasing the code so someone doesn't release a compiled version (each source could be different, have individual certificates, etc., thus compiled versions would individually identifiable), but I'd reckon the price would be so reasonable that it wouldn't be worth the effort.
By revenue-neutral I mean the price of the product would not only cover wages, administration but also necessary reserves. I've mentioned this concept on HN and elsewhere previously for software such a Gimp, LibreOffice and so on.
I'm somewhat surprised there aren't any software organizations that use this development model.
Because a lot of niche OSS has very little commercial value to even try and be revenue neutral.
Even take ReactOS, why in the world would a org use it when you could just license Windows properly with PCs pre built and have the accountants depreciate them into taxes as they are capital equipment.
If someone needs an old Windows kernel for compat, they'll just keep using that old Windows version they have on a box and not waste engineering labor to migrate it.
Combining a bunch of projects like that under a halfway house increases revenue but does not mean it will be revenue neutral. It'll still be in the red.
End of the day, there are reasons why some OSS stays completely free while others have commerical and free operations ran in parallel. Either it can bring in money or it can't.
If they are read only file systems it will disrupt any malware on the router. I’ve reversed routers whose file system only allows signed executables, and update packages. It’s good practice. I give the same advice to people and their phones, reboot regularly.
It’s much easier to entertain constantly when one half of the relationship has the availability to do it.
If I’m mistaken, then holy heck how did your grandparents do it lmao.