Risky Biz News: The Linux CNA mess you didn't know about:
The Linux Kernel project was made an official CVE Numbering Authority (CNA) with exclusive rights to issue CVE identifiers for the Linux kernal in February this year.
While initially this looked like good news, almost three months later, this has turned into a complete and utter disaster.
Over the past months, the Linux Kernel team has issued thousands of CVE identifiers, with the vast majority being for trivial bug fixes and not just security flaws.
Just in May alone, the Linux team issued over 1,100 CVEs, according to Cisco's Jerry Gamblin—a number that easily beat out professional bug bounty programs/platforms run by the likes of Trend Micro ZDI, Wordfence, and Patchstack.
Ironically, this was a disaster waiting to happen, with the Linux Kernel team laying out some weird rules for issuing CVEs right after the moment it received its CNA status.
We say weird because they are quite unique among all CNAs. The Linux kernel team argues that because of the deep layer where the kernel runs, bugs are hard to understand, and there is always a possibility of them becoming a security issue later down the line. Direct quote below:
"Note, due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify. This explains the seemingly large number of CVEs that are issued by the Linux kernel team."
[...] Instead, the Linux Kernel team appears to have adopted a simpler approach where it puts a CVE on everything and lets the software and infosec community at large confirm that an issue is an authentic security flaw. If it's not, it's on the security and vulnerability management firms to file CVE revocation requests with the precise Linux Kernel team that runs the affected component.
The new Linux CNA rules also prohibit the issuance of CVEs for bugs in EOL Linux kernels, which is also another weird take on security. Just because you don't maintain the code anymore, that doesn't mean attackers won't exploit it and that people wouldn't want to track it.
The Linux team will also refuse to assign CVEs until a patch has been deployed, meaning there will be no CVEs for zero-days or vulnerabilities that may require a longer reporting and patching timeline.
[...] And if this isn't bad enough, the Linux kernel team appears to be backfiling CVEs for fixes to last year's code, generating even more noise for people who use CVEs for legitimate purposes.
[...] Unfortunately, all of this CVE spam also could have not happened at a worse time. Just as the Linux Kernel team was getting its CNA status, NIST was slowing down its management of the NVD database—where all CVEs are compiled and enriched.
NIST cited a staff shortage and a sudden rise in the number of reported vulnerabilities—mainly from the IoT space. Having one of every fifth CVE being a Linux non-security bug isn't helping NIST at all right now.
(Score: -1, Offtopic) by Runaway1956 on Saturday June 08, @12:59PM
https://www.theatlantic.com/ideas/archive/2024/05/bureaucratic-bloat-eating-american-universities-inside/678324/ [theatlantic.com]
https://www.psychologytoday.com/us/blog/talking-about-health/202108/bureaucracy-in-time-pandemic [psychologytoday.com]
Ancient Chinese curse: May you live with ever growing bureaucracies.
OK, maybe I made that last one up. Or, maybe I just don't know who to attribute the curse to.
Here, we have a brand new bureaucracy that isn't going to waste decades in bloating itself, and intruding into everyone's lives.
Do political debates really matter? Ask Joe!
(Score: 4, Interesting) by stormreaver on Saturday June 08, @01:04PM (1 child)
This is the kind of crap that gets your commit rights revoked. While every bug has the potential to be a security issue, not every bug is a security issue. Don't file a CVE unless a real security issue can be identified. Otherwise, you're just as bad as Viagra spam.
(Score: 3, Interesting) by driverless on Saturday June 08, @07:33PM
That's why some in the security industry refer to CVE as Curriculum Vitae Enhancement. Some submit CVEs because they care about security, many submit CVEs because it Enhances their CV.
(Score: 3, Informative) by pTamok on Saturday June 08, @01:06PM (18 children)
In reverse order:
An EOL kernel is End-of-Life. It gets no further support. People running EOL kernels need to move to non-EOL kernels. Yes, it is hard, but supporting kernels indefinitely is even harder, especially with limited resources.
All bugs are potential security bugs. Greg Kroah-Hartman has made it quite clear. [soylentnews.org]
So, what can you do about it to protect yourself?
It's a message people don't want to hear. Lots of "But surely...", or "I'm a special case...".
(Score: 1, Touché) by Anonymous Coward on Saturday June 08, @02:30PM (8 children)
"EOL kernels need to move to non-EOL kernels."
And when your computer or interface which doesn't have baked-in spyware is no longer supported,
join the flock, sheeple.
(Score: 2, Insightful) by pTamok on Saturday June 08, @03:00PM (7 children)
It's GPL 2.0.
You can fork the EOL kernel that supports your hardware and do your own updates. If there's enough people needing to do the same, you can share the load.
If there is special hardware that can be supported by later kernels with a little driver work, then do that, sharing where necessary.
It's not like proprietary software where out-of-support means you are out of options. With GPL software you have the source, which you can modify, together with like-minded folk (if they exist), or pay someone to maintain/modify/support it.
The linux kernel comes with no warranty or guarantee of fitness for purpose. If you want more than the level of service you've already paid for, you need to either contribute your own time and resources, or pay someone else to do it.
There is other software you can use: Microsoft Windows, one of the BSDs, possibly others e.g. QNX.
Linux has a pretty good record for supporting older hardware. Your efforts and/or money can make it better, both for yourself, and others. The GPL is like that.
(Score: 3, Interesting) by NotSanguine on Saturday June 08, @11:47PM (5 children)
Conceptually, you're absolutely correct.
But IoTs are the glaring exception that breaks that line of reasoning. Especially cheap stuff like Amazon and Roku sticks, cameras, alarm system sensors and all manner of other devices (including "smart" phones) which will never (even before EOL) receive any updates -- let alone a kernel update. And once the device is EOL or out of support -- your only option will be to use the old software (assuming the vendor doesn't brick the device altogether) without updates and/or buy a new device.
How many people, outside of tech folks with dev skills and specialized knowledge/software/hardware are able to get into their devices, will be able to hack their Kindle, Nest, Echo, Ring, etc., etc., etc. as you suggest?
So no. You and I can absolutely update kernels on general purpose computing systems, but even we would have a difficult time doing so for a Ring, an Echo, or any of dozens of other devices without reasonable console access and/or an emulator flashing mechanism.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 1) by pTamok on Monday June 10, @08:20AM (4 children)
Why do you buy things that lack the correct, basic, minimum long-term support?
(Score: 2) by NotSanguine on Monday June 10, @09:56AM (3 children)
I do where I can. But I may not have a choice, as it might be embedded in something else or it may not exist at all.
Please provide me with commercial products that provide "basic, minimum long-term support."* This includes companies that will *never* go out of business and who will provide software support and updates *forever*:
Light bulbs
car infotainment systems
"smart" Doorbells
"smart" TVs
"smart" speakers
refrigerators
washing machines
ovens
toothbrushes
sex toys
etc.. etc., etc.
So many vendors don't ever provide any updates and often will just discontinue a product, often by *bricking* the device, with no recourse.
Are you really that divorced from the current state of embedded devices or are you just being deliberately obtuse?
*Note that any entries must be available from common (to the hoi polloi, not tech folks) retail outlets and must not require the end user to flash or compile anything, assuming they could anyway.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 3, Insightful) by pTamok on Monday June 10, @02:34PM (2 children)
Light bulbs - my light bulbs have no network connectivity.
car infotainment systems - my ICE has no end-user update function. It will be updated by the garage, if necessary. It does have network connectivity, as it tells me what CD I'm playing, with a track listing, but nothing more useful. The manufacturer is trying all sorts of trick to get me to pay for network connectivity, and I'm not buying.
"smart" Doorbells - My doorbell is a sprung switch, default off, which rings a bell when pressed.
"smart" TVs - My TV has no network connectivity. It isn't 'smart'
"smart" speakers - My speakers have no network connectivity or processors of any kind.
refrigerators - My refrigerators have no network connectivity. They likely have a microcontroller for the display and temperature alarm.
washing machines - My washing machine has no network connectivity. It likely has a microcontroller for operating the various programs, and for the display.
ovens - My ovens have no network connectivity. A light extinguishes when they reach the set temperature, probably via a potentiometer/thermocouple set up.
toothbrushes - My toothbrush has no network connectivity, but probaby a microcontroller controlling the operations timer.
sex toys - I would not buy sex toys with network connectivity.
I'm not being obtuse. I buy well-engineered products. If a well-engineered product is not available, then I don't buy. Why do people work against their own best interests by buying tawdry stuff?
(Score: 2) by NotSanguine on Monday June 10, @04:33PM (1 child)
Your use case doesn't hold for everyone.
I don't use any of that "smart" shit either. But dismissing the 98% of consumers because *you* are way "smarter" than they are seems kind of reductive.
That said, you do you. I wish you only luck and success.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 1) by pTamok on Monday June 10, @05:28PM
I'm probably way more stubborn than the average bear. It's not always in my own best interests, so I'm probably not smart.
On the other hand, I don't want to buy (expensive) stuff that can be 'bricked' in an instant, causing me a great deal of inconvenience. Perhaps I'm just more than usually risk-averse.
(Score: 3, Insightful) by maxwell demon on Sunday June 09, @06:35AM
Yes, you could fix security bugs yourself (or pay someone to fix them) is you were informed that they exist. Which you likely are not if no CVEs are issued.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 5, Touché) by sigterm on Saturday June 08, @03:02PM (5 children)
Yes. And that is entirely beside the point.
Following that logic, if a company like Cisco are made aware of vulnerabilities in older, unsupported products, they shouldn't have to warn the public about it, much less issue firmware updates for such products.
Greg Kroah-Hartman may be a skilled developer, but he obviously hasn't thought particularly hard about the actual purpose of a CVE.
CVEs should be issued when a security vulnerability has been determined to exist. Not when a security vulnerability might exist, because in that case a permanent, unfixable CVE for the Linux kernel itself needs to be issued immediately. Because if every bug is a potential security flaw, and every product has bugs pretty much by definition, then every product represents a potential security risk due to it potentially having bugs.
If you say "I don't know whether this affects security or not, so I'll just create a CVE and leave it to Someone Else to figure out the details," then you're clearly not the right person (or organization) to be a CNA.
Sure. And what does that have to do with CVEs?
If you seriously think that it's the responsibility of the end user to know whether their router or application runs an EOL Linux kernel, or that companies that may even have gone out of business should be the ones responsible for continuously testing their old products, then I don't know which planet you're living on, but I hope the view is nice since there's obviously something weird in the atmosphere.
This is by the way the polar opposite argument from the "let's create CVEs for everything" stance the Linux Kernel Team have currently taken. Because they also seem to argue that if someone else discovers an actual security vulnerability in an EOL kernel, they shouldn't have to create a CVE.
So to summarize: Whenever the Kernel Team finds a bug, any bug, a CVE should be created regardless, but if someone else discovers a genuine security vulnerability in an older kernel that may very well still be in active use, it should be ignored because of that kernel's EOL status. That's completely bonkers, and anyone putting forth such an argument should be removed from the decision-making process forthwith.
(Score: 4, Informative) by VLM on Saturday June 08, @03:21PM (1 child)
You're probably not going to like this, but I used to work in this field and if you know the magic terms to google for like "LDoS" its pretty easy to find:
https://sec.cloudapps.cisco.com/security/center/resources/security_vulnerability_policy.html [cisco.com]
So, uh, yeah, unironically Cisco follows exactly the same policy that the Linux guys are following.
OK fine you can argue post LDoS router firmware is not the same word as post EOL kernels, but its nearly word for word the same concept.
(Score: 3, Interesting) by sigterm on Saturday June 08, @04:31PM
You're correct about the policy, which makes sense for a for-profit business (which is why I also pointed out that it's unreasonable to expect companies that may or may not even be in business to test and patch their old products), BUT:
On several occasions, Cisco (among others) have indeed issued firmware updates that a) were made available for free, despite a policy stating that paid subscriptions were required, and b) updated products that were classified as EOL.
And why did these companies deviate from their stated policies in those instances? Because CVEs were created, identifying flaws and rating their severity.
The focus of a CVE is the vulnerability, not the support status of the product or the profitability of the manufacturer. Bringing those factors into the discussion muddies the waters and betrays a lacking understanding of the purpose of the CVE program:
The Linux kernel development team (and Greg Kroah-Hartman in particular) have failed quite spectacularly in this regard.
(Score: 2, Funny) by pTamok on Saturday June 08, @08:42PM (2 children)
There is the possibility that he has thought hard and deeply about this. He has commented on linux security, and backporting patches for years, having had the responsibility for maintaining the LTS kernels.
It is the responsibility of the end-user to take measures to assure that the products and services they buy and/or use meet their security requirements. Not everyone is a security expert, or a kernel expert, or know what is the latest kernel, or even what a kernel is. If you buy a product that uses the linux kernel, it is for the producer to meet a reasonable security standard. Sadly, many fail, with (for example) WiFi routers running old, well out-of-support kernels with non-mainline patches. Need I mention Android...
Getting an adequate service requires paying money, or having access to significant (free to you) expertise.
If users have no idea, then the people providing services to those users ought to have a clue. Unfortunately, there is money to be made in providing security colanders and running away, rather than good security management. People are often seduced into buying something cheap that looks as though it does the job, rather than something more expensive that does the actual job. (Only this morning I heard someone complaining that the cheap copy of a well-known brand thing they had bought fell apart on first use. The price they paid was less than one tenth of the well-known brand's price.) Users do need to take responsibility and not wail that being a cheapskate comes back to bite you every so often.
You don't need to be a kernel expert, just like you don't need to be a food hygiene regulations expert to eat in restaurants, or a motor mechanic to get your car serviced. You buy a service. The people you buy the service from are meant to be the professionals.
What is the difference between 'a bug' and 'a genuine security vulnerability'? Can you offer a well defined process for telling the difference. A lot of people would like just such a thing.
EOL kernels do not get support. What is so difficult to understand about that? If you use an EOL kernel, you are taking a risk, just like eating food after the 'use-by' date. Do you insist food manufacturers provide food that never expires?
(Score: 1, Touché) by Anonymous Coward on Saturday June 08, @11:53PM
Thanks for the laugh. I needed a good one today.
(Score: 4, Insightful) by maxwell demon on Sunday June 09, @07:12AM
A bug is an unintentional deviation of actual behaviour of intentional behaviour. It may or may not be a security vulnerability.
A security vulnerability is behaviour that allows to get access to data or functionality they shouldn't have access to. It may or may not be a bug.
An example of a bug that clearly is no security vulnerability is a typo in an error message. There is no way someone could exploit a misspelling in an error message.
An example of a security vulnerability that is not a bug is an included backdoor (like the one that was in xz). It's not a bug because it was intentionally included, but it is very clearly a security vulnerability.
Can you offer a well defined process to determine that a software is bug free? You report bugs when you identified a bug. Not if you just aren't sure that there's no bug.
CVEs are the same. You file them when you identified a security vulnerability. Not when you just can't exclude that there is one.
Now I trust the Linux kernel developers that all security vulnerabilities in the kernel are likely bugs (I say likely because there's always the possibility of a sufficiently camouflaged backdoor in submitted code that did not get caught be the kernel developers; it's unlikely but not definitely excluded). But not every bug is a security vulnerability.
CVEs are not support. What is so difficult to understand about that?
If I want to know a list of all known bugs in the Linux kernel, I go to the Linux bug tracker. That's what the bug tracker is for.
If I want to know a list of all known security vulnerabilities in the Linux kernels, I go to the CVE list. That's what the CVE list is for.
If the CVE list contains all bugs, whether or not they have been identified as security risk, then the CVE no longer serves its purpose, but is demoted to a mere mirror of the bug tracker.
No, but I do insist that they don't suppress information about known specific dangers of eating certain food after the use-by date.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 3, Insightful) by RamiK on Saturday June 08, @03:28PM
Precisely this. Pontificating over the potential security implications of already-fixed bugs simply doesn't work. Every few weeks we hear about some years-long Windows or iOS bug that been de-prioritized and ignored when first reported only to be exploited in secret for years-to-come in secret since some other related code path was modified and no one reevaluated things.
If your product is connected, you can deliver fixes OTA. If you want to dick around with evaluating whether it's "worth it" for your special snowflake system, do it on your own time and money to thrift through what the kernel already patched up.
There's multiple multiple years-long LTS releases to choose from including the CIP super LTS with near-flawless security track record provided people simply keep up with releases: https://www.kernel.org/category/releases.html [kernel.org] https://www.cip-project.org/faq [cip-project.org]
Pick one and stick to it. It's not too hard.
compiling...
(Score: 4, Insightful) by maxwell demon on Sunday June 09, @06:32AM (1 child)
And a CVE is a good argument to get someone actuually more to a newer kernel. While an absence of CVEs, especially while many new CVEs are filed for newer kernels, may be interpreted as "newer kernels are obviously more insecure, better stay with the old kernel, that seems to be secure".
The Tao of math: The numbers you can count are not the real numbers.
(Score: 1) by pTamok on Monday June 10, @08:17AM
The only argument for moving to a newer kernel that you need is that the kernel you are using is End-of-Life. If you ignore that, you are also capable of ignoring CVEs.
If people are incapable of interpreting End-of-Life correctly, than I am not sure they can be helped.
Sure, people run cars on worn-out tyres with inadequate tread-depth. They eat food beyond it's 'use-by' date. They go to the bus-stop in the sure knowledge that the bus is 'always' late. They exceed posted speed limits. Often they get away with it.
Running on a time-expired kernel is the same. You don't need any other warnings. Often you will get away with it. Until you don't.
One a kernel is time-expired, it gets No Further Support. That includes security vulnerability checking/administration. The resources are better used elsewhere. What is so difficult to understand?
(Score: 5, Insightful) by Unixnut on Saturday June 08, @01:09PM (1 child)
Quite frankly a lot of Linux has become a disaster waiting to happen in the last 10 or so years. I mean Linux was always a loose collection of hacks, but this wasn't such a big deal when Linux was a niche hobby OS run by enthusiasts for enthusiasts. For flexibility, hackability and rapid feature development Linux is top IMO, to this day.
However things like stability, bug fixing (especially security bugs), etc.. are rarely considered. After all developers like to hack on things they enjoy, and very few find joy in bug fixing (especially other peoples) and security flaw handling. That usually gets lumped with upstream to handle (including sometimes the end users).
Thing is now Linux runs most of the serious IT infrastructure of the world, and this attitude does not match with that responsibility.
I always thought the Linux kernel team as a whole were by far the most professional, simply by virtue of (many of them) being paid kernel developers and the kernel being the core of every single Linux system out there (including derivatives like Android). If anything there should not be any issues with funding preventing them from doing things properly.
This CVE mess however has thrown my above belief in doubt. They seem to be treating the CVE database like a "potential security bug" tracking system, odd considering they already have their own internal tracking system.
Also their "due to the layer" excuse also sounds weak to me. They are not the only kernel on earth. There are other OSes, and yet I've not heard of any similar issues with Microsoft, Apple or FreeBSD OS'es. They somehow managed to handle their kernel security issues and CVEs just fine without resorting to what the Linux kernel devs are doing.
(Score: 3, Informative) by driverless on Saturday June 08, @07:08PM
It's not just the Linux kernel, various Linux distros who are CNAs have taken a similar approach, everything we spot is a CVE until proven otherwise. Oh, and since we're the CNA you have to prove it to us, but since we've already decided in advance that it's a CVE there's no way to make it not a CVE any more once we say it is.
(Score: 3, Interesting) by VLM on Saturday June 08, @03:29PM (1 child)
Usually at BigCorporate you see this behavior when either they're trying to save money so have lower paid hires do the same thing for every ticket every time until AI can replace them, or when they're in a CYA battle because someone got burned for only tagging 99.9999% accurately so F them we're tagging 100% regardless if it needs tagging or not to CYA.
"We're too cheap and unskilled to realistically ever take responsibility" vs "We refuse to take responsibility as an office politics strategy"
I'm just curious if anyone in the know can discern which scenario fits better. I think its the former; could be the latter.
(Score: 1) by pTamok on Saturday June 08, @09:11PM
My (unpopular) view is that it is closer to the latter. I suspect they are pointing out that the Emperor has no clothes.
(Score: 2) by Ox0000 on Saturday June 08, @04:08PM (5 children)
Let me ask a broader question: what _actually_ is the purpose of the CVE program? Why does a security vulnerability get a special - often 'external' - CVE number rather than just a tag/label in the bug tracking system of the affected software (one that, for instance, says "Security")?
I'm asking because these days "getting a CVE" seems to be a goal of so-called "security researchers" that are no better than writers for tabloid magazines: always on the lookout for gotcha's rather than actually contributing something.
So I'll ask the question again: what actually is the purpose of having a special number outside of the regular bug tracking system of the affected software? What does one actually _do_ with such a a number in the real world that couldn't be done with the regular bug tracking system already? How does one actually, in the real world, use that CVE number?
(Score: 2, Disagree) by Ox0000 on Saturday June 08, @04:34PM (3 children)
Forgot to mention this as well: I understand the words used on https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures#CVE_usage [wikipedia.org]
However, I still don't know what a CVE actually offers that is not offered by, e.g., a project's own issue tracking software. The whole "oh but we need a common name across systems to talk about the same thing" seems BS to me, as that's what the URI (you know, a UNIVERSAL resource identifier) to the actual bug (in the actual issue tracking system or even as a blog post) would do. Why duplicate a "truth" in multiple places (CVE system and issue tracking system)?
If it's identification you want (first sentence of that "Usage" section on Wikipedia), then why muddy the waters with two systems having a moniker for the bug (CVE and bug ID), rather than one single, authoritative, system that is the project's issue tracking system?
(Score: 3, Informative) by sigterm on Saturday June 08, @04:56PM
You wanted to know about CVE, but instead of visiting their actual web site you went to Wikipedia, of all places?
From the front page of cve.mitre.org:
And as for your other question:
Visibility, for one thing. I'd rather have a common database, a one-stop-shop for all security vulnerabilities if you will, than having to visit tens or even hundreds of bug trackers. And I'm pretty sure most security researchers and tech journalists feel the same way.
(Score: 3, Informative) by canopic jug on Saturday June 08, @04:57PM (1 child)
I looked into the nature of CVEs over ten years ago and found that they had become very inconsistent in scope and assessment of severity. Once upon a time they were actually useful and, if I recall correctly, even contained ways to check if your system was vulnerable and steps for mitigation. Now they're just a lot of yammering. Since severity varies a lot, some remote exploits are given a low score and others are just plain scaremongering. Daniel Stenberg wrote quite a bit about bogus CVEs [daniel.haxx.se] since various interests were using CVEs to cast aspersions against cURL.
The granularity or scope is way off from vendor to vendor as well. A very long time ago, m$ learned to combine as many bugs as possible under a single CVE but only for the older versions of their products. The aggregation allowed them to dishonestly assert that their systems were becoming more secure as evidenced by having fewer CVEs. The omission of the latest version from the CVE allowed them to issue a press release saying that "it is not known to be affected, buy the upgrade" for a few days until the full CVE came out containing reference to even the latest version.
When I looked into the CVEs regarding their scope and serverity, I thought it might be possible to normalize them so that one could make actual relevant comparisons. However, as I dug into the task, I saw it would take months or years to normalize even a few quarters worth of CVEs and was unwilling to do that for free or even for what passes for a masters degree these days.
Money is not free speech. Elections should not be auctions.
(Score: 3, Interesting) by sigterm on Saturday June 08, @05:07PM
You're absolutely on point here, but I believe you've identified a problem with the CNAs, not necessarily the CVE system as such.
Using the number of issued CVEs as a metric is one thing, but to then simultaneously allow vendors to become CNAs and submit and classify CVEs for their own products without oversight creates perverse incentives to misreport and mis-classify vulnerabilities.
(Score: 3, Interesting) by darkfeline on Saturday June 08, @10:09PM
Put bluntly, CVEs are a way to get people to update their shit.
For most software most of the time, you only need to update to get new features. If you don't need the new features, you're better off not updating lest it break something.
CVEs provide a standard way to be alerted to security issues in versions of software you use, and to which version you need to update. They also allow you to figure out if the security issue is relevant or not (e.g., if KeePassXC has a security issue in the browser plugin but you don't use the browser plugin then you don't have to update).
They're also a convenient tool for auditors and such.
Join the SDF Public Access UNIX System today!
(Score: 2, Interesting) by Anonymous Coward on Saturday June 08, @09:40PM (9 children)
Even if it isn't intentional, it sounds like it's in spirit of those CIA manuals for sabotage. 🤣
https://www.cia.gov/static/5c875f3ec660e092cf893f60b4a288df/SimpleSabotage.pdf [cia.gov]
(Score: 0) by Anonymous Coward on Sunday June 09, @03:24AM (8 children)
Look at Windows 11.
So what are the options? I'm not going to switch to MacOS. The MacOS and Desktop Linux UI etc is worse for me than the UI on older versions of Windows.
(Score: 3, Insightful) by maxwell demon on Sunday June 09, @08:00AM (7 children)
The Desktop Linux UI?
Which one are you talking about? Gnome? KDE? Cinnamon? Mate? Note that this list isn't exhaustive.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Sunday June 09, @12:50PM (4 children)
GNOME, KDE and Xfce. None of them are as good for my usage as Windows 7's UI.
A few examples:
1) Right click, Send to - various stuff (GUI tail, GUI grep, hex editor, media player, etc)
Example: https://www.pcmag.com/how-to/how-to-customize-the-send-to-menu-in-windows [pcmag.com]
Advantages: can easily open arbitrary file(s)/folder(s) with an arbitrary program. AND the programs can be quickly added/removed to/from the "send to" list by running: shell:sendto and adding shortcuts to the folder.
2) Right click, git/svn GUI diff of Word or Excel document.
Example: https://www.youtube.com/watch?v=jO-n_mLlUhs [youtube.com]
Advantages: can easily do GUI diff of Word or Excel documents and compare the changes.
3) Double height taskbar where task buttons are not grouped, show labels and are ordered like:
1234
5678
Instead of:
1357
2468
Advantages: can quickly identify and select window/task out of many windows (e,g, same app with multiple opened documents e.g. excel or word with multiple opened documents). When window is closed not as many task buttons change their relative position.
And that's not all.
Of course, Windows 11 isn't good for this either...
If you can recommend a Desktop Linux UI that supports the 3 items I mentioned, or does them better/faster, then I might be interested. I'm not going to waste more time trying out the zillions of distros/ desktop linux options. I've already tried three of the major ones, and nope.
And if it requires extra add-ons, customization and configuration then it has to still work after updates without me having to redo stuff. Keep in mind I hear the Windows 11 UI can be changed too with 3rd party add ons.
FWIW I do use Linux for server stuff.
(Score: -1, Troll) by Anonymous Coward on Sunday June 09, @02:34PM
Keep on using Windows. No one besides you cares.
(Score: 3, Informative) by linuxrocks123 on Sunday June 09, @07:04PM (2 children)
XFCE supports the thing you want.
Thunar -> Edit -> Configure Custom Actions
Happy Linuxing :)
(Score: 0) by Anonymous Coward on Monday June 10, @02:24AM (1 child)
(Score: 3, Informative) by maxwell demon on Monday June 10, @07:06PM
I'm pretty sure 2) is not a feature of Windows itself but of TortoiseSVN (for repositories) and Microsoft Office (for Word/Excel files). I don't know if TortoiseSVN offers this also for some Linux DEs. I'm pretty sure Microsoft Office doesn't exist for Linux.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Sunday June 09, @02:29PM (1 child)
Don't forget xfce!
(Score: 1) by pTamok on Monday June 10, @05:37PM
There's always Ratpoison.
Ratpoison: The worst Linux Desktop Environment of all time [substack.com]
Arch Linux: Ratpoison [archlinux.org]
NonGNU.org: Ratpoison [nongnu.org]
Wikipedia: ratpoison [wikipedia.org]