Bash or csh don't have to know about "drive letters", just like they don't need to know about /vol, or /usr. It is just part of the file path and any file path that the OS understand is fine for bash or csh.

As for" forward" [sic] slashes, c:/xyz is a valid path for windows. Even if it weren't, the completion logic in at least bash is fully pluggable so it would just* need a completion module to support backslashes, besides recompilation, ironing out niggles that would creep in and bug fixing.

Even if bash completion weren't pluggable, Microsoft could edit the source code to support backslash file completion. So even after making multiple wrong assumptions in your argument's favor, your argument is still wrong.

*If bash code turns out to be non-portable, the work will be a bit more.

Laptops have 2 distinct uses :

1. More mobile : carrying the laptop, using it for short bursts in cramped or otherwise inconvenient locations temporarily. Here, most people make do without peripherals for very short , very inconvenient work and minimal peripherals for somewhat longer, less inconvenient work. It is here that hubs are yet another inconvenience and 2-3 ports might do some good.

2. Desktop replacement : Once settled in one's den, use many many peripherals. But even here, hubs are less convenient than port replicators / KVM etc.

Only for very specific intermediate uses between these - say a "portable den", hubs might be of the use you mention.

This non-transferability will have to transfer across change in corporate structures otherwise the trolls will blackmail against that event. Then it doesn't give much protection because the original patent holder or seller might incorporate into a challenging company. Again you need "no sue clause" into the patent sale - either inherently or negotiated separately.

And it protects only original patent holder - so "selling" a bought patent will hold that risk.

A perpetual license to one's own patent can always be negotiated very easily even under current patent laws. This is because patent owner is always the monopolist so can name his terms if it is a big company. And big companies wouldn't mind giving perpetual license to an individual / very small company because they don't pose much of a threat.

Sun revolving around the Earth wasn't a difficult problem to solve either. Nor was another planet. Nor yet another.

I agree it is not suitable for the regular kind of patent trolls. But it will give rise to a new kind of patent trolls.

A business making use of some patents cannot price each patent separately. Loss of any patent is disastrous - dependent on business model, supply chain length etc. A troll can blackmail this business by the fear of buying ONE of those essential patents.

This gives rise to the necessity of being able to group patents and paying tax and selling only the whole group, not one of those patents individually. This then will be exploited by the new trolls who will group together diverse patients. Only weapon against them will be to buy their big group of patents, which is comparable to the current weapon of buying out the whole payment troll company.

Discrimination is banned, in certain ways, not caste "system". In fact, government itself discriminates by reserving jobs, promotions, college admissions, so you will understand if someone find idiotic your statement of caste" system " being "banned ". And besides discrimination, there are a million other aspects to the caste "system ".

There have been such programs many times, but " most people " are so far from honestly taking advantage of the programs that it is funny someone calls outhouses a common feature in Indian society. The programs get taken advantage of, if at all, by collecting the money and NOT building the outhouse.

Your statement implies "most people"
1. already have an outhouse,
2. have running water supply,
3. neglect to fix its leaks and
4. instead focus on getting a better smartphone.

The first two points are extremely incorrect.

Caste "system" is not banned and it never was. Even the British loved it as it was a nice way to divide people. Complexity of Indian caste system lends itself to creative uses.

"Most people" in India don't have an outhouse, most of those who have , don't have any running water to their outhouses.

Those with running water to their outhouses don't have any need to practice economy. So you are wrong in every way.

Possible, but I see you are factually wrong.

No one in the whole thread is advising identifying files manually. Different people are proposing file names, extensions, content etc. all non-manually / automatically / programmatically / transparently to the end user.

And I never said putting this information in file name is a good strategy, so why you litter your post with such irrelevant content is beyond me. This is why I read but am not addressing more than half of this post of yours too.

I got it. You are among the proponents of evil bit. I agree information security is trivial once we get all the evil people to set this evil bit. Real life is not so simple - web servers areone of the least trustworthy elements in a typical user's computing life.

In RFC 3514 world, yes. In real life, this "metadata" will need to be edited, or distrusted. So we do need to identify a file. In the face of this imperfect world, there are certain difficulties. Whether it is a perl script or a jpeg image can best be figured out from looking at file content.

NOT from file name.
NOT from metadata set by untrustworthy people.

Yes, wherever some information is, it has to be read and processed. ANY information.

Many applications can be used to process jar files as well as zip files. In as much as they use the same container, they ARE the same type of files. In as much as the purpose is different, there should be another data to be read somewhere. Remember you could change the "separate" metadata from application/zip to application/jar - so ALL the confusion that results from decisions taken by examining file content are all possible in decisions taken by examining the separate metadata.

But in this separate metadata, not only the OS might attempt running a zip application on a jar file, it could also run photoshop on an excel sheet. Which is a much more varied possibility, testing against is many orders of magnitude more difficult than testing security of zip applications opening jar files, and hence much much more risky.

Yes, so rather than execute a regexp of "any complexity", just run a multi-megabyte application on it because that is not a risk.

Irrelevant.

Which is a good thing. A perl script IS different from an image, even though an image can be made to look like a perl script by relatively minimal change. Actual security scenario around the file has changed by that change in "in-data identifiers".

Which is again a good thing. A file triggering notepad by default being converted into a file triggering photoshop by default IS a modification to the file's most common behaviour. Why should it not require a write access?

I think either you don't know what you are talking about, or you haven't understood the thread subject at all. I repeat my example - "The context is that OS components need to distinguish between an image and a perl script."

Exactly the same is wrong with extension approach too. Double clicking on a .emacs file in windows comes with error "Windows can't open this file".

Both are issues of the database not being updated, not fundamental problems in the approaches. But looking at content to decide about the content at least makes half a sense. Looking at an independent variable - last few characters of the file name makes zero sense and is a fundamental problem in the approach.

The context is that OS components need to distinguish between an image and a perl script. The only difference between them that is significant in this context is in the content of the file. So it is a poor idea to examine anything else other than the file itself.

File name, extension, mimetypes, separate changeable attributes are all poor ideas when the file itself is available for examination.

Which 2 classes? "Data" and "executable"? There is no distinction as long as interpreters exist. Spread sheets are data, but if opened in MS Excel can perform actions that many executables find difficult. Many many applications change registry when just opening "data" files. It is easy to make a file which is both a csv and a perl script.

Then there are zero day, and decades old vulnerabilities in many applications where a "maliciously" crafted data file can get the application to run arbitrary code.

For a regular human being, there is no possible way of distinguishing data from applications.

As long as interpreters exist, there is no difference between 'load this file in its proper application' and 'run this application'. You have to go full iOS and disable "interpreters", loosely defined.

From my perspective, this is the worst. Command line showing one name, explorer showing another name of the SAME folder. There are even applications which show the "internal" name, and some show the so-called "user friendly" name.

There is only one utility of things having a name - and that is that it doesn't keep changing depending on circumstances. Otherwise there is no point in anything having any name.

That is assuming backup strategy for all pictures is the same, that for all music is the same etc. This is a VERY bad assumption - leaving with 2 options :

1. Analyze the 120 GB documents, pictures and music spending 3 hours. Still, worst case backup 120 GB.
2. Backup 120 GB across documents, pictures and music.

Only one of those folders makes sense - Downloads. This is because it is unlikely one would want to backup downloads. But other backup strategy has nothing to do with whether something is called a document, or a picture or "a music".

Google gives me 3 results :

1. One is your slashdot post
2. One about memes with a quote written on an obese lady saying "lowering minimum wage will increase the number of jobs". No explanation/description.
3. One heritage.org, saying somewhat orthogonally "Increased Minimum Wage Does Not Reduce Poverty"

First try answering this question which has proven hard enough for you.