Hacker Newsnew | past | comments | ask | show | jobs | submit | 7bit's commentslogin

15 years back people were given Windows macOS and Linux and people voted which OS were ready for the Desktop and which were not. The only BS is your inflammatory contribution to this topic.

Nope, Macs were expensive stuff games did not run on, and linux was just not pushed by near anyone.

It was not a war "which desktop is easier to use", it was "which system can run stuff I need". And if "the need" was "video games and office stuff", your only choice was windows.


The average user only cares what they can run on the desktop. Linux did not have as much choice back then.

they were not, they purchased what was in the stores, which was only windows. all the way from first windows to windows xp it was the biggest pile of shit imaginable. the average user wouldnt even have half a chance of installing it, and certainly couldnt use it with any kind of reasonableness, it was a giant mess, it was just the mess people were used to. Most people would throw out their computer and buy a new when windows became slow, because, of course it gradually becomes slower, makes perfect sense, no?

KDE from 15 years back was HUGELY better than windows at the time, and frankly, also windows now


Was he ever competent in something, tho?

Ah. That would be the Dilbert Principle:

> Unlike the Peter principle, the promoted individuals were not particularly good at any job they previously had, so awarding them a supervisory position is a way to remove them from the productive workflow.

> An earlier formulation of this effect was known as Putt's Law (1981), credited to the pseudonymous author Archibald Putt ("Technology is dominated by two types of people, those who understand what they do not manage and those who manage what they do not understand.").

https://en.wikipedia.org/wiki/Dilbert_principle


And behind on a lot of stuff. The Microsoft's ACLs are nothing short of one of the best designed permission systems there are.

On the surface, they are as simple as Linux UOG/rwx stuff if you want it to be, but you can really, REALLY dive into the technology and apply super specific permissions.


The file permission system on Windows allows for super granular permissions, yes; administrating those permissions was a massive pain, especially on Windows file servers.

And they work on everything. You can have a mutex, a window handle or a process protected by ACL.

> The Microsoft's ACLs are nothing short of one of the best designed permission systems there are.

You have a hardened Windows 11 system. A critical application was brought forward from a Windows 10 box but it failed, probably a permissions issue somewhere. Debug it and get it working. You can not try to pass this off to the vendor, it is on you to fix it. Go.


Procmon.exe. Give me 2 minutes. You make it sound like it's such a difficult thing to do. It literally will not take me more than 2 minutes to tell you exactly where the permission issue is and how to fix it.

Procmon won't show you every type of resource access. Even when it does, it won't tell you which entity in the resource chain caused the issue.

And then you get security product who have the fun idea of removing privileges when a program creates a handle (I'm not joking, that's a thing some products do). So when you open a file with write access, and then try to write to the file, you end up with permission errors durig the write (and not the open) and end up debugging for hours on end only to discover that some shitty security product is doing stupid stuff...

Granted, thats not related to ACLs. But for every OK idea microsoft had, they have dozen of terrible ideas that make the whole system horrible.


Especially when the permission issue is up the chain from the application. Sure it is allowed to access that subkey, but not the great great grandparent key.

Shitty security products being inscrutable isn't limited to Windows. "Disable SELinux" anyone?

While that's true, linux _tends_ to follow the rules a bit better, and not change how APIs work from under your feets. For instance on Linux, permission checks are done when you open a handle. An LSM like SELinux can only allow or deny your rights to open the handle at the permission level you requested, that's it. It cannot allow the handle to be opened, but with less privileges than requested, nor can it do permission check at operation time. So once your open is successful, you can be pretty sure that you've cleared the permission checks bar, and are good to go.

This makes writing robust code under those systems a lot easier, which in turns makes debugging things when it goes wrong nicer. Now, I'm not going to say debugging those systems is great - SELinux errors are still an inscrutable mess and writing SELinux policy is fairly painful.

But there is real value in limiting where errors can crop up, and how they can happen.

Of course, there is stuff like FUSE that can throw a wrench into this: instead of an LSM, a linux security product could write their own FS overlay to do these kind of shenanigans. But those seem to be extremely rare on Linux, whereas they're very commonplace on Windows - mostly because MS doesn't provide the necessary tools to properly write security modules, so everyone's just winging it.


At this point you're just arguing for the sake of bashing on Microsoft. You said it yourself, that's not related to ACL, so what are you doing, mate? This is not healthy foundation for a constructive discussion.

Is this a trick question, because you run it as administrator in a sandboxed account.

and why is it not on the vendor of the critical application?

Because they aren't allowed on the system where it is installed, and also they don't deal with hardened systems.

Do you have any favorite docs or blogs on these? Reading about one of the best designed permissions systems sounds like a fun way to spend an afternoon ;)

And yet, it requires kernel extension anti-cheat to stop a game mod from reading and writing memory locations in a running process. It’s a toy operating system if it can’t even prevent that. It’s why corporate machines are so locked down. Then there is the fact video drivers run in ring 0 and are allowed to phone home… but hey you can prevent notepad++ from running FTW.

You have ACLs on linux too

ACLs in Linux were tacked on later; not everything supports them properly. They were built into Windows NT from the start and are used consistently across kernel and userspace, making them far more useful in practice.

Also, as far as I know Linux doesn't support DENY ACLs, which Windows does.


Yes it does.

since when?

Since some of us could be bothered reading docs. Give it a try and see how it works out for you.

Some of us can! I certainly enjoy doing it, and according to "man 5 acl" what you assert is completely false. Unless you have a particular commit or document from kernel.org you had in mind?

> Each of these characters is replaced by the - character to denote that a permission is absent in the ACL entry.

Wouldn't the o::--- default ACL, like mode o-rwx, deny others access in the way you're describing?


See 6.2.1 of RFC8881, where NFSv4 ACLs are described. They are quite similar to Windows ACLs.

Here is kernel dev telling they are against adding NFSv4 ACL implementation. The relevant RichAcls patch never got merged: https://lkml.org/lkml/2016/3/15/52


https://www.rfc-editor.org/rfc/rfc8881#section-6.2.1

I see what I misunderstood, even in the presence of an ALLOW entry, a DENY entry would prohibit access. I am familiar with that on the Windows side but haven't really dug into Linux ACLs. The ACCESS CHECK ALGORITHM[1] section of the acl(5) man page was pretty clear, I think.

[1] https://man7.org/linux/man-pages/man5/acl.5.html#ACCESS_CHEC...


Haha, sure. Sorry, it's not you, it's the ACLs (and me nerves). Have you tried configuring NFSv4 ACLs on Linux? Because kernel devs are against supporting them, you either use some other OS or have all sorts of "fun". Also, not to be confused with all sorts of LSM based ACLs... Linux has ACLs in the most ridiculous way imaginable...

Not by default. Not as extensive as in Windows. What's your point?

Oh yeah for sure. Linux is amazing in a computer science sense, but it still can't beat Windows' vertically integrated registry/GPO based permissions system. Group/Local Policy especially, since it's effectively a zero coding required system.

Ubuntu just recently got a way to automate its installer (recently being during covid). I think you can do the same on RHEL too. But that's largely it on Linux right now. If you need to admin 10,000+ computers, Windows is still the king.


Debian (and thus Ubuntu) has full support for automated installs since the 90's. It's built into `dpkg` since forever. That include saving or generating answer to install time questions, PXE deployment, ghosting, CloudInit and everything. Then stuff like Ansible/Puppet have been automating deployment for a long time too. They might have added yet another way of doing it, but full stack deployment automation has been there for as long as Ubuntu existed.

> Ubuntu just recently got a way to automate its installer (recently being during covid). I think you can do the same on RHEL too. But that's largely it on Linux right now. If you need to admin 10,000+ computers, Windows is still the king.

1. cloud-init support was in RHEL 7.2 which released November 19, 2015. A decade ago.

2. Checking on Ubuntu, it looks like it was supported in Ubuntu 18.04 LTS in April 2018.

3. For admining tens of thousands of servers, if you're in the RHEL ecosystem you use Satellite and it's ansible integration. That's also been going on for... about a decade. You don't need much integration though other than a host list of names and IPs.

There are a lot of people on this list handling tens of thousands or hundreds of thousands of linux servers a day (probably a few in the millions).


> Ubuntu just recently got a way to automate its installer (recently being during covid).

Preseed is not new at all:

https://wiki.debian.org/DebianInstaller/Preseed

RH has also had kickstart since basically forever now.

I've been using both preseeds and kickstart professionally for over a decade. Maybe you're thinking of the graphical installer?


> Ubuntu just recently got a way to automate its installer (recently being during covid). I think you can do the same on RHEL too. But that's largely it on Linux right now. If you need to admin 10,000+ computers, Windows is still the king.

What?! I was doing kickstart on Red Hat (want called Enterprise Linux back then) at my job 25 years ago, I believe we were using floppies for that.


Yeah, I have been working on the RHEL and Fedora installer since 2013 and already back then it had a long history almost lost to time - the git history goes all the way back to 1999 (the history was imported from CVS, as it predates Git) and that actually only cover the first graphical interface - it had automated installation support via kickstart and a text interface long before that, but the commit history has been apparently lost. And there seems to have been even some earlier distict installer before Anaconda, that likely also supported some sort of automated install.

BTW, we managed to get the earlies history of the project written down here by one of the earliest contributors for anyone who might be interested:

https://anaconda-installer.readthedocs.io/en/latest/intro.ht...

As for how the automated installation on RHEL, Fedora and related distros works - it is indeed via kickstart:

https://pykickstart.readthedocs.io/en/latest/

Note how some commands were introduced way back in the single digit Fedora/Fedora Core age - that was from about 2003 to 2008. Latest Fedora is Fedora 43. :)


Still the king but developing/testing/debugging group policy issues is a miserable experience.

I disagree. Group policies are extremely straightforward to administer in my experience.

That depends on how fine grained your targeting rules are. They can get insane.

I always found it straight forward. Never had an issue and I've implemented my fair share on thousands on devices and servers.

Not an implementer of group policy, more of a consumer. There are 2 things that I find extremely problematic about them in practice.

- There does not seem to be a way to determine which machines in the fleet have successfully applied. If you need a policy to be active before doing deployment of something (via a different method), or things break, what do you do?

- I’ve had far too many major incidents that were the result of unexpected interactions between group policy and production deployments.


That's not a problem with group policy. You're just complaining that GPO is not omnipotent. That's out of scope for group policies mate. You win, yeah yeah.... Bye

I'm surprised no one has said NixOS yet.

He's the person I want to meet the least from all the people in the world, he is that much of my hero.

"known" is the wrong word. Laymen know a lot of things, like ingesting lead, radium, mercury and arsenic. Up until a couple of years ago, people "knew" that one glass of wine a day was healthy, when infact every drop is poisonous to the body.

In reverse, people thought (and too many still "know") that MSG and pasteurization is bad.

Don't use the word know, when in fact you mean "assume".


Is MSG not bad for you in the way aspartame is not bad for you? I totally get that MSG is naturally present in dashi but the chemistry of dashi (a very messy and complex mix of substances) vs purified msg is going to be different, and the concentrations the japanese consume food containing dashi are very different to the way UPFs and chinese restaurants gratuitously smother your food in it. MSG is to many cuisines what butter is to western cuisine (ie moar is always bettah)

There’s no evidence linking MSG specifically with any chronic health issues and little reason to suspect there would be in healthy people at the quantities generally consumed. Funnily enough many people who are wary of MSG and try to avoid it would be better off looking at their sodium intake, which we know for sure has long term health risks.

I am someone who is sensitive to MSG and the new substitutes they put in food to replace it.

It is not "dangerous", and I think that is the problem with the messaging, but it does increase my anxiety, insomnia and fibromyalgia symptoms. And I also thing for most people it is fine, but it certainly does not work with my family's genetics. My mother had the same issue.

Many things in food now replace MSG. Any time you see a protein isolate, what they are isolating is the glutamate. Malted Barley Flour also contains high levels of glutamate and purines (like inosine) that work synergisticly with it to enhance flavor.

Glutamate is an excitatory neurotransmitter, and it makes your taste buds more "excited". My mouth tastes like metal whenever I have foods with glutamate. It is not pleasant for me at all.

https://pmc.ncbi.nlm.nih.gov/articles/PMC9883458/

https://www.eurofins.com/media-centre/newsletters/food-newsl...


Well it seems pretty accepted that refined sugar is worse for you than consuming sugars locked up in fibrous fruits. From a similar intuition glutamates locked up in natural sources probably has a different bioavailability profile to refined MSG, incidental sodium intake notwithstanding.

In any case, everyone is different and catchall health advice lacks nuance. I have to very consciously consume more and more salt because I habitually cut it out to the point that I now suffer from hyponatremia especially as I exercise and sweat bucket loads.


salt is bad again?

Salt's bad if you have sodium-responsive hypertension (maybe 30% of the population).

salt was always advised to be limited, especially for those with high blood pressure. This hasn't changed, there are just vocal diet ideologues (mostly carnivore/keto) that are trying to post-hoc rationalize otherwise.

From what I understand it's only really a problem for a specific set of high blood pressure folks. Something genetic I think.

I'm on blood pressure medication, and haven't received any advice about sodium intake.


Only ~50% of the population is hypertensive, and only about half of them are sodium sensitive.

Everybody is sodium sensitive, it’s a basic fact that your body retains additional fluids if you increase your sodium intake, just talk to some bodybuilders. Chronic long term exposure to a high sodium diet is a risk factor for all sorts of issues because of this basic fact of biology. Way more so than MSG or even artificial sweeteners. But people focus on the wrong thing.

My understanding is that most people's blood pressure does not increase in response to dietary sodium, which is the sensitivity described in this context.

And half of the half that are sensitive, it lowers blood pressure.

MSG is only bad for you because it makes things taste amazing so you are going to eat more than you actually should. Nothing wrong with butter btw.

As with most food stuffs if not consumed in moderation it can become a problem.


MSG is very safe in normal quantities with a similar safety profile to salt. You can drink MSG water to kill yourself but it’d be like drinking a gallon of seawater. It’s monosodium glutamate. Monosodium as in NaCl (table salt) and glutamate as in the amino acid and neurotransmitter. Once they disassociate in water, they’re both some of the most basic molecules used by all life, including for protein production.

A glass of wine a day is within epsilon of the most healthy possible option. You're making this out as if this is a big shift, but it isn't. There are just huge error bars on the measurements relative to the effect of the intervention.

Ah yes. American Prisons prioritizing punishment over resocialising is the reason why criminals so often continue to hurt society after they have been released.

Then we have people who demand to double down on the punishment and wonder why these people never stop breaking the law.

Americans are a marvelous bunch. Thanks Dog I live in a first world country.


I don't think you know what humble job means, and meant to say humiliating pay.

Obviously your co-worker was not able to do it in a few minutes with a free program, or he would just have done it this way.

I have three Ubuntu servers and the naming pisses me off so much. Why can't they just stick with their YY.MM. naming scheme everywhere. Instead, they mostly use code names and I never know what codename I am currently using and what is the latest code name. When I have to upgrade or find a specific Python ppa for whatever OS I am running, I need to research 30 minutes to correlate all these dumb codenames to the actual version numbers.

Same with Intel.

STOP USING CODENAMES. USE NUMBERS!


As an Apple user, the macOS code names stopped being cute once they ran out of felines, and now I can't remember which of Sonoma or Sequoia was first.

Android have done this right: when they used codenames they did them in alphabetical order, and at version 10 they just stopped being clever and went to numbers.


Ubuntu has alphabetical order too, but that's only useful if you want to know if "noble" is newer than "jammy", and useless if you know you have 24.04 but have no idea what its codename is and

Android also sucks for developers because they have the public facing numbers and then API versions which are different and not always scaling linearly (sometimes there is something like "Android 8.1" or "Android 12L" with a newer API), and as developers you always deal with the API numbers (you specify minimum API version, not the minimum "OS version" your code runs in your code), and have to map that back to version numbers the users and managers know to present it to them when you're upping the minimum requirements...


> Ubuntu has alphabetical order too, but that's only useful if you want to know if "noble" is newer than "jammy"

Well, it was until they looped.

Xenial Xerus is older than Questing Quokka. As someone out of the Ubuntu loop for a very long time, I wouldn't know what either of those mean anyway and would have guessed the age wrong.


Yes, I agree, codenames are stupid, they are not funny or clever.

I want a version number that I can compare to other versions, to be able to easily see which one is newer or older, to know what I can or should install.

I don't want to figure out and remember your product's clever nicknames.


They can't. They used to, until they tried to patent 586...

Trademark.

Protip, if you have access to the computer: `lsb_release -a` should list both release and codename. This command is not specific to Ubuntu.

Finding the latest release and codename is indeed a research task. I use Wikipedia[1] for that, but I feel like this should be more readily available from the system itself. Perhaps it is, and I just don't know how?

[1] https://en.wikipedia.org/wiki/Ubuntu#Releases


> Protip, if you have access to the computer: `lsb_release -a` should list both release and codename. This command is not specific to Ubuntu.

I typically prefer

  cat /etc/os-release
which seems to be a little more portable / likely to work out of the box on many distros.

That's only if the distro is recent enough; sooner or later, you'll encounter a box running a distro version from before /etc/os-release became the standard, and you'll have to look for the older distro-specific files like /etc/debian_version.

> you'll encounter a box running a distro version from before /etc/os-release became the standard

Do those boxes really still exist? Debian, which isn't really known to be the pinacle of bleeding edge, has had /etc/os-release since Debian 7, released in May 2013. RHEL 7, the oldest Red Hat still in extended support, also has it.


> the oldest Red Hat still in extended support, also has it.

You would be alarmed to know how long the long tail is. Are you going to run into many pre-RHEL 7 boxes? No. Depending on where you are in the industry, are you likely to run into some ancient RHEL boxes, perhaps even actual Red Hat (not Enterprise) Linux? Yeah, it happens.


> Do those boxes really still exist?

Yes, they do. You'll be surprised by how many places use out-of-support operating systems and software (which were well within their support windows when installed, they have just never been upgraded). After all, if it's working, why change it? (We have a saying here in Brazil "em time que está ganhando não se mexe", which can be loosely translated as "don't change a (soccer) team which is winning".)


Try cat /etc/os-release. The codenames are probably there. I know they are for Debian.

Thank you! I was just about to kvetch about how difficult it was to map (eg) "Trixie" == "13" because /etc/debian_version didn't have it... I always ended up having to search the internet for it which seemed especially dumb for Debian!

Same problem I have with Debian.

At least Fedora just uses a version number!


I like to think that Buster, Bullseye, and Bookworm was a ploy to make people more dependent on the version number.

I work with Debian daily and I still couldn't tell you what order those go in. but Debian 12, Debian 13, etc.. is perfectly easy to remember and search for.

Debian is trying hard to switch to numbers. It's the user base that is resisting the change.

Maybe they should stop synlinking the new versions after 14, because AFAIK, they already tried everything else.


Yeah if they just stopped using a release name that'd probably do it, although communities can be surprisingly stubborn on some things.

Exactly this. Every second update, there is something new that I typically disable or revert. The amount of stuff that is added and not opt-in in the last few years is just tiring.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: