If the pilot wants to damage the plane intentionally and make it look like it was not intentional, they could act as if airplane controls are not working, act surprised at it and keep acting as if trying to save the plane.
No, it is not only not that simple, but it is plain wrong. Productivity improvements using, say, technology, can help a vast majority of people beat inflation, sometimes even everyone.
For someone to get market beating returns, someone else mustn't. But don't conflate market beating with inflation.
How often do suicidal bus drivers drive off a cliff? Suicidal operators of huge industrial machines take down their workplace? Pretty rare, even if there are hundreds of times as many bus drivers / heavy machine operators as compared to airline pilots.
Many countries have zero effective regulation on bus driver / machine operators sleep cycles. Lots of drivers / operators work without any social interaction which could have helped detect and even prevent suicidal tendencies. This pilot was at least working along with another human being. Was in Europe - which at least on paper had good sleep cycle regulations, and knowing Europe, regulations would have had some force of effect too.
There could have been other reasons for this event. Your ignorance of them do not make those reasons stop existing.
But except saying it "dramatically" improves results, the StringBuilder result wasn't worthy of a mention or a compare against disk performance.
Obviously, like any good "researcher" does, the conclusion was written first and then the "experiment" was performed. Any results contradicting the conclusion have to excluded.
The above explanation applies to any data structure that has to be stored contiguously and increases in size, or is immutable
But it was never necessary for the "in memory operation" (their words) to use an immutable data structure. If you use bad data structure when using in-memory, of course in-memory will be slower than disk.
This "researcher" is an idiot. The java code given at the bottom of the "research paper" uses + operator to concatenate strings. This is O(N) in Oracle java. Total algorithm becomes O(N*N) in memory, and O(N) on disk.
Obviously N*N takes longer than N after a certain N even when N*N is running on faster memory.
You make it sound like starvation is necessary for effective weight loss. This is extremely incorrect.
The way fat (especially saturated) has been maligned by "experts" in 80s, 90s and early 2000s - millions of people have gained weight just by eating too much carbohydrate. Just replacing some of it by fat makes for tastier, more filling, body weight reducing, and health giving food. Quite the opposite of starvation.
For very rapid body fat loss, you might have to go on very low carbohydrates - which while not starving, does need to fight the other animal in the body which craves carbohydrates, simpler the better.
Currently i an having to use a database as a slow shared memory between different instances of the application (kind of a cluster, but not exactly). Do you intend to never run multiple instances of your application working together, say, under a load balancer?
Yes, but this gives English the googleability advantage. English has another advantage in the technology world- only 26 characters make keyboards easy to make and use. 26 is one of the lowest of any language.
If the people of the US liked to eat so much, they wouldn't export humongous quantities of eatable stuff. And would pay enough to the farmer to make more than 20k per year.
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.
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.
the original patent holder could retain a non-transferable license to use his patent but
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.
or perhaps only has to sell a non-transferable license
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.
It doesn't seem like too difficult a problem to solve
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.
caste system that persists in spite of being banned by government and very conservative views on many issues.
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.
It's also a country where most people will rather buy a slightly more expensive phone than replace their outhouse with a running water toilet.
"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.
My view is that we shouldn't be identifying files manually AT ALL.
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.
They should be part of the meta-data, as already is whenever you download a file. Just because it ends in.docx doesn't mean it's sent to you as application/microsoftworddocument (or whatever it is) by your browser. In fact, you can break stuff easily that way if you don't populate your webserver with proper mimetypes
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.
In fact, you can break stuff easily that way if you don't populate your webserver with proper mimetypes.
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.
But from that point on, we don't NEED to ever identify a file again
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.
And encoding the filetype into the file means that you have to examine (and potentially interpret) the file to work out what to open it in.
Yes, wherever some information is, it has to be read and processed. ANY information.
That's fine for certain things (e.g. executables all start with MZ) but not for others (e.g. JAR files are indistinguishable from ZIP until you interpret the ZIP file contents and act upon that interpretation).
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.
As soon as the contents could be malicious, and you're running even a regexp of any complexity on it, it's a risk.
Yes, so rather than execute a regexp of "any complexity", just run a multi-megabyte application on it because that is not a risk.
Encoding it into the filename itself is shoving metadata into other metadata. There's even a metadata separator involved here, the period in between! As such, they should be two separate and independently changeable pieces of information. Parsing the filename to work how to interpret the data inside is a nonsense, when you could just store "filename" (without the extension) and "filetype" separately. This also allows.jpg and.jpeg to be seen as the same thing (which they are!) and not require two separate and confusing entries!
Irrelevant.
Adding any in-data identifiers to existing files also means modifying the file, potentially modifying hashes and security on them.
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".
Changing the way they are interpreted on one machine will affect every machine they are visible on and require write-access to the file.
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.
Slashdot Mirror
No it can't. He just has to pretend the levers/knobs are jammed. Touch interface is difficult to spoof.
If the pilot wants to damage the plane intentionally and make it look like it was not intentional, they could act as if airplane controls are not working, act surprised at it and keep acting as if trying to save the plane.
Camera never records intentions.
Beating inflation doesn't cause inflation.
No, it is not only not that simple, but it is plain wrong. Productivity improvements using, say, technology, can help a vast majority of people beat inflation, sometimes even everyone.
For someone to get market beating returns, someone else mustn't. But don't conflate market beating with inflation.
so this copilot is a complete scumbag
You do not know enough to conclude this.
How often do suicidal bus drivers drive off a cliff? Suicidal operators of huge industrial machines take down their workplace? Pretty rare, even if there are hundreds of times as many bus drivers / heavy machine operators as compared to airline pilots.
Many countries have zero effective regulation on bus driver / machine operators sleep cycles. Lots of drivers / operators work without any social interaction which could have helped detect and even prevent suicidal tendencies. This pilot was at least working along with another human being. Was in Europe - which at least on paper had good sleep cycle regulations, and knowing Europe, regulations would have had some force of effect too.
There could have been other reasons for this event. Your ignorance of them do not make those reasons stop existing.
Where there is a perhaps, there is no judgement.
But except saying it "dramatically" improves results, the StringBuilder result wasn't worthy of a mention or a compare against disk performance.
Obviously, like any good "researcher" does, the conclusion was written first and then the "experiment" was performed. Any results contradicting the conclusion have to excluded.
The above explanation applies to any data structure that has to be stored contiguously and increases in size, or is immutable
But it was never necessary for the "in memory operation" (their words) to use an immutable data structure. If you use bad data structure when using in-memory, of course in-memory will be slower than disk.
This "researcher" is an idiot. The java code given at the bottom of the "research paper" uses + operator to concatenate strings. This is O(N) in Oracle java. Total algorithm becomes O(N*N) in memory, and O(N) on disk.
Obviously N*N takes longer than N after a certain N even when N*N is running on faster memory.
It's difficult, but reliable.
No way. Impossible. Simplicity is prerequisite for reliability - Edsger Dijkstra.
You make it sound like starvation is necessary for effective weight loss. This is extremely incorrect.
The way fat (especially saturated) has been maligned by "experts" in 80s, 90s and early 2000s - millions of people have gained weight just by eating too much carbohydrate. Just replacing some of it by fat makes for tastier, more filling, body weight reducing, and health giving food. Quite the opposite of starvation.
For very rapid body fat loss, you might have to go on very low carbohydrates - which while not starving, does need to fight the other animal in the body which craves carbohydrates, simpler the better.
Currently i an having to use a database as a slow shared memory between different instances of the application (kind of a cluster, but not exactly). Do you intend to never run multiple instances of your application working together, say, under a load balancer?
Yes, but this gives English the googleability advantage. English has another advantage in the technology world- only 26 characters make keyboards easy to make and use. 26 is one of the lowest of any language.
If the people of the US liked to eat so much, they wouldn't export humongous quantities of eatable stuff. And would pay enough to the farmer to make more than 20k per year.
So already the farmer owning the land is suboptimal use of that land. Why should the society bend over backwards to encourage that?
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.
the original patent holder could retain a non-transferable license to use his patent but
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.
or perhaps only has to sell a non-transferable license
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.
It doesn't seem like too difficult a problem to solve
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 that persists in spite of being banned by government and very conservative views on many issues.
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.
It's also a country where most people will rather buy a slightly more expensive phone than replace their outhouse with a running water toilet.
"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.
We're talking at cross-purposes.
Possible, but I see you are factually wrong.
My view is that we shouldn't be identifying files manually AT ALL.
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.
They should be part of the meta-data, as already is whenever you download a file. Just because it ends in .docx doesn't mean it's sent to you as application/microsoftworddocument (or whatever it is) by your browser. In fact, you can break stuff easily that way if you don't populate your webserver with proper mimetypes
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.
In fact, you can break stuff easily that way if you don't populate your webserver with proper mimetypes.
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.
But from that point on, we don't NEED to ever identify a file again
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.
And encoding the filetype into the file means that you have to examine (and potentially interpret) the file to work out what to open it in.
Yes, wherever some information is, it has to be read and processed. ANY information.
That's fine for certain things (e.g. executables all start with MZ) but not for others (e.g. JAR files are indistinguishable from ZIP until you interpret the ZIP file contents and act upon that interpretation).
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.
As soon as the contents could be malicious, and you're running even a regexp of any complexity on it, it's a risk.
Yes, so rather than execute a regexp of "any complexity", just run a multi-megabyte application on it because that is not a risk.
Encoding it into the filename itself is shoving metadata into other metadata. There's even a metadata separator involved here, the period in between! As such, they should be two separate and independently changeable pieces of information. Parsing the filename to work how to interpret the data inside is a nonsense, when you could just store "filename" (without the extension) and "filetype" separately. This also allows .jpg and .jpeg to be seen as the same thing (which they are!) and not require two separate and confusing entries!
Irrelevant.
Adding any in-data identifiers to existing files also means modifying the file, potentially modifying hashes and security on them.
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".
Changing the way they are interpreted on one machine will affect every machine they are visible on and require write-access to the file.
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.