Also note, very few people in Denmark uses electric heating as you can get hot water from centralized production into your home (not clean only for use in radiators). My parents gets their heating from a power plant 20km away.
Not to nitpick, but danes refer to that centralized production as "surplus heat". The "surplus" heat is heat generated as a bi-effect from producing electricity.... - from coal. So, when the electricity all comes from wind, the danes need to find some other way to heat their houses during winter.
How do prepared statements handle the not uncommon situation where you want to include an "in" clause? For example:
select * from customers where city in ?citylist
This was the problem they tried to solve by dynamically creating a statement like:
select * from customers where city in (?city-1, ?city-2, ?city-3)
So, to generate the -1, -2, and -3 parts they relied upon the index of the array.
Only in PHP an array will turn around and bite you with it's dual personality as a hash table. A hash table where one key was not "-1" but rathersomething like (pseudo):
-1); drop table students; --
You cannot really fault the Drupal developers for trying to support this commonly occurring pattern, for which there are no good solutions with plain prepared statements. After all, if they could write secure code for a common problem that could prevent less experienced developers for falling back to error-prone and insecure string interpolation.
Don't get me wrong: The drupal developers is at fault. But they were set up by the criminally insecure PHP.
While the responsibility for this rests with Drupal, they were set up by another strange design decision of PHP: The fact that arrays are also hashtables and vice-versa. There are *tons* of these strange design decisions in PHP.
I'm sure we can do some stuff with signed repositories and signed packages to detect when things 'change' and/or keep unsigned repositories 'untrusted'.
Suggestion: For "trusted" repositories, toenable automatic updating, developers must sign the original install package with a certificate. Self-issued certs could be ok for this part. Any subsequent updates must be signed with the *same* certificate. If not, it will *not* automatically update - even if the repository is "trusted". OneGet clients will only allow auto-update if the product/vendor names are the same and the certificate public key is the same. Otherwise a warning should be issued and the local administrator should choose whether to trust the new cert going forward.
The installer should put abc.dll in the same directory as the.exe file instead of a shared location.
No!
If the DLL is indeed candidate for being shared (e.g. part of a shared product) it should put the assembly/DLL in the Global Assembly Cache (GAC). This is a side-by-side store where the same assembly/DLL can exist in multiple versions.
If security vulnerabilities are found and a patch is released, only the version in the GAC needs to be updated, often by registering a new version with a manifest/redirection that will ensure that anyone requesting the old (vulnerable) version will be treated to the new (fixed) version.
Windows Installer does this. And supports patching.
Yes, Linux never solved dependency hell, it has been swept under the rug that is distro+version specific repositories. The problem is still very, very real, but if you constrain yourself to the repositories of the distro + version that you use, the package maintainers will have ensured that the package dependencies do not conflict with each other and with the version of the ABI that your distro+version is on.
DLL hell was *very* real in the Windows 9x days. Side-by-side assemblies was introduced with Windows 98SE (IIRC) - but really only became de rigueur with Windows XP. During the 9x days, software developers took advantage of the fact that nothing prevented them from writing files to the system directories. When they encountered a problem where they needed a DLL - they simply installed it in the system directory - often overwriting whatever was there before. Obviously this caused all sorts of problems where only the latest installed product had a robust state.
Rather than leaving the dependency resolving responsibility to package maintainers, the Windows OS contains a brokering mechanism that will load the correct version of an assembly - even if multiple versions of the same assembly exists in the global assembly.
Linux package managers have dual responsibilities: Provide available software (with update mechanism) and ensure dependency hell does not rear its ugly head. Linux dependency hell is very real, once you step outside the repositories.
Windows has binary compatibility with software that was developed for Windows 95 / Windows NT 3.1 (where Win32 debuted). The dependency problem (called DLL hell in Windows) was solved with the SxS and the broader use of the Windows Installer package manager, which integrated with SxS.
After going to the Youtube page, I gotta say - Just what the fuck?
So now in order to salve the wounds of people butthurt by the monumental sucakge of Windows 8, will be treated to the awesome best ever spectacle of rotating menu items, what they've always been waiting for?
Ahem. The youtube link (showing the flipping menus) shows a Linux desktop. It was intended by submitter jonas-supa to show how much more advanced Linux desktops are.
Can't wait until the fanbois come out and tell us how waiting for a menu to spin around a few times is based on extensive research done by Microsoft that proves once and for all that most users want the operating system to waste their fucking time, and that anyone who doesn't just love the steaming hot piece of shit is an idiot who doesn't kow that they are doing.
Lol. We have to wait for the Linux fanbois to explain why the hell Linux needs compiz and all of the (agreed: Horrid!) animations from that youtube link.
The whole article is de-indexed. That is the only way it can work
What? Google already uses a huge directory of "stop words" - words or phrases that should not be indexed. What is required is that they can create such stop words per link (article). Maybe they are not done with that yet, but it could certainly work that way.
The goal is not to suppress articles, the goal is to protect individuals right to privacy. Google does not control the article, and they should not remove all links (associations) to articles. But they can and should respect individuals right to privacy. So when an association is outdated, irrelevant or misleading they should - upon request - remove the association - not the article, not all the other links to the article.
And yes - that includes the right to delete associations between your name and a possible crime you committed 30 years ago. Most modern judicial systems (US the notable exception) recognize that when you've done your time you have "paid" your debt to society - and should have a chance to start over. If youthful stupidities will follow you your entire live you will *never* get a chance to prove that you have corrected yourself.
And this is NOT just for criminals. Controversies, your participation in demonstrations, debates, political parties, deliberate smear campaigns etc. all have the potential to seriously inhibit your chances with future employers.
Was the article removed in its entirety, or was the *association* between the name and the article removed.
Of course Google should not remove the entire article. That was never what the law said. If they did so, it was just another blatant attempt at manipulating opinions of journalists in the hope that journalists reporting will start sway public opinion.
If it was just the *link* between a commentator name and the article that was removed, i.e. you would still find the article through googling words from the content of the article, then what is BBSs problem?
Google is blatantly trying to manipulate public opinion through journalists. They are deliberately misinterpreting the law to create an impression of draconian consequences.
People can write equally vulnerable code in Python or Java or Ruby.
Nonsensical. Yes, given enough effort, one can certainly write equally vulnerable code in Python or Java or Ruby. That does not prove *anything*
This particular vulnerability is directly triggered by a extremely poor PHP design decision: To conflate arrays and hashtables. The Drupal developers wrote some code that on the surface looks sorta ok. But it assumes that the passed array has numerical indexes.
But in their wisdom, PHP designers decided that separate data structures were too complex for programmers to understand. Alas, arrays as hashtables are the same, since one could view an array as "just" a hashtable that happens to use integers as keys.
The code in question assumed that it could retrieve the "position" of a value in the array and use that. Only, when the position was text with PHP or SQL attack code it led to a vulnerability.
There is NO way to compare that to vulnerabilities created by Python, Java or Ruby developers. Given the exact same lines of thought - which are not at all "out there" the same way of thinking woul NOT have led to a serious vulnerability in any of those languages.
PHP is just bad, bad design. And the bad design is dangerous.
It wasn't a bug in bash, it was working exactly as expected. What wasn't expected was web devs passing in data directly from the Internet into bash. Bash incorrectly assumed that environmental variables were assigned from a trusted source.
Nope. It was a bug. While it was the intention that bash would "import" function definitions from env vars, it was *never* the intention that it would directly and without confirmation execute any commands *following* the function definitions in the env vars.
1 - ISight claims this has been a five year campaign and then add that "hackers began only in August to exploit a vulnerability found in most versions of Windows". So where did the "five year" timeline come from?
2 - "Russian hackers target NATO, Ukraine and others" the article screams and then we find this wishy washy explanation from ISight's John Hullquist on his claim about the hackers being Russian:
Sounds like a bunch of FUD to me
While I suspect that ISight (like all "security research" companies) deliberately stirs the pot (it helps generate awareness of their products), they do not actually claim that the specific vulnerability has been used for 5 years.
One could imagine that the "Sandworm" operation has been ongoing for 5 years. If they continually and persistently try to infiltrate NATO and other organizations they will probably use whatever opportunity presents itself. They actually also try to exploit vulnerabilities that have long been patched, hoping to hit an unpatched machine.
So while they do try to sensationalize, it is conceivable that the hacker group is older than just the most recently used vulnerability.
Microsoft is not a state-owned enterprise, and has no allegiance to any state. It has a responsibility only towards its shareholders, and apparently the business model of selling flawed software is very profitable.
As opposed to doling out flawed software for free?
does IIS pass headers along to CGI scripts the same way Apache does?
Are you fucking kidding? You get them out of a collection that's a property on the request object. They aren't shat into arbitrary fucking shell environment variables, like someone's freshman year CompSci project. Grow up!
I believe that it is the CGI specification that requires parameters to be passed as environment variables. So if you use CGI on IIS it should work the same way.
That would not trigger this issue, however, as it requires some script to expand the environment variable and it is not an automatic braindead expansion like in bash. The most common environment variables to be expanded %WINDIR%, %USERNAME% and the like. Not ever have I seen someone write %HTTP_USER_AGENT% or any other %HTTP_*% expansion. There's no systemic failure as with bash Shellshock.
But to be fair, it *does* look like an injection vector. Yes, GGP blatantly ignored that the claim I made was about PowerShell - not cmd.exe - but there seems to be an issue, and it just reinforces my point that shells (i.e. Windows shells included) that conflate text and instructions are error prone by default.
It is the exact same type of vulnerability that have existed in other weakly-typed shells since their inception. This is the reason why you should use -print0 with find before passing it to any other program: If you do not you risk that the filename is an injection attack.
The culprit is the idea that a shell is just some form of text interpreter that will interpret anything that is text. There is no semantic separation of "text" and "executable".
Unfortunately, this "code is just text" has become so entrenched in shell scripting that it is vulnerabilities waiting to happen. Process substitution, subshells etc all rely on this very property.
At least with PowerShell there is no such stupidity. In PowerShell you have to indicate specifically each time you want text interpreted and executed. PowerShell script block is a separate type (actually, a lambda) from text, integers, dates, decimals etc. The ease of how you pass executable content (script blocks) even over the network removes most reasons to interpret text as executable commands.
Or you could use what we've been using for the past 20-30 years that has been debugged, proven to work and not completely different to the rest of the world.
Does anyone really want "better localization" in terminals. My experience as a bilingual user from windows is that the less things are localized the better they work.
I have to agree that you usually experience fewer problems if you just run as english. I do the same. I should not be that way, however.
Making commands localized breaks script compatibility. (And that includes any output if that is parsed too.)
That is (one of) the problems actually solved (on Windows) by PowerShell: Typed parameters and strong typing eradicates such parsing bugs
For processes more than 2 days old: ps | ? starttime | ? starttime -lt (get-date).adddays(-2)
It has gone to the point where I get the English version of Windows rather than one adapted to my native language.
Me too, but not because of the CLI; rather the sooner availability of service packs and tech previews. Also, I cannot stand the mingling of languages in dialog boxes where some text is provided by the OS and some by the application.
The localization of some of the folder names makes things break and the translation of GUI elements obfuscates the function and makes it so that one has to translate everything to English and back to realize what the function is, especially when the original translator used every synonym for "device" he could possibly find.
This lets bash execute anything as the afflicted user.
Yeah and who exactly is this afflicted user? Right, normally apache or some other unprivileged user who has relatively little power though granted you don't even want unprivileged users logging in from the Internet
You are one setuid/SUID utility away from total system compromise. Even one such utility that invokes bash (or the default shell which is bash on Fedora and RH systems) and your box isn't yours any more.
Shellshock is *also* a privilege escalation vulnerability when exploited locally. Granted, you need to find such a setuid utility. But the utility does not need to be vulnerable by itself. It just needs to invoke the shell through system() or similar.
I would have no qualms about this practice if it were completely up front in it's entirety rather than have to read about it in a blog.
This is quote from the page where you agree to the terms of the preview program (this is the top text - the first you read):
Accept the Terms of Use and Privacy Statement
This should be the most boring step. Accept the Terms of Use and Privacy Statement and we can finish up your registration.
By accepting the Terms of Use and Privacy Statement, you agree that:
* The experimental and early prerelease software and services might not be fully tested.
* You might experience crashes, security vulnerabilities, data loss, or damage to your device.
* Your detailed usage and device data will automatically go to Microsoft and our partners to improve our products and services. See the Privacy Statement for more information.
* You will receive communications about the program and related promotions. Once you’ve joined the program, to stop receiving such communications you must leave the program.
Some of this stuff will probably just concern the free Technical Preview, but there's still a clear trend of Microsoft turning Windows into a datamining platform. It started with Windows 8 where they try to get the user to log into their own computer with a Microsoft account. It seems to be only getting worse.
In Windows 10 you can choose not to use a Microsoft account - just like with Windows 8.
On top op that, Windows 10 will allow corporations to federate their own AD - which means that you will get the device-sync features *without* creating a Microsoft account.
What if someone who privately knows about the vulnerability gets the idea to exploit various installations of competitors (or even common users!) during the embargo period? Do you trust large enterprises not to misuse their knowledge to their own advantage?
A patch cannot be prepared "privately" without a number of people knowing about it: Developers, testers, reviewers, server admins etc. At each of the organizations that are privy to the predisclosure.
There are money to be made from that. To gain access to an exploitable vulnerability before a patch can be distributed broadly is a massive opportunity.
What if someone starts to sell off their knowledge to blackhatters?
What if someone sets up what looks like a legitimate business (a fake antimalware) and uses it primary to get inside info?
I know it is a database, and slightly optimized. "A few records" would not affect query time, especially if they were not in the query path.
What about a lot of records? And how about a lot of records that are in the query path?
It's a database. IIRC it uses B* trees. Search time is proportional to the logarithm of total number of records. Even "a lot" of records may not cause the height of the tree to increase. You generally need to *square* the number of records to double to search time.
At the same time, the registry hives are really, really robust. Windows keeps to redundant copies and even protects writes through the kernel transaction manager as well as the journal of the file system. Corruption is virtually impossible until the hard drive decays to a state where even the redundancy cannot make up for it anymore. Unlike text files, both metadata *and* data are guaranteed to either succeed in an atomic transaction.
(compare to the Unix way, where config files can be corrupted if the system/power fails during a write: File system do not guarantees *data* consistency for regular files, only *metadata* consistency, i.e. the fs guarantees that its internal structures will not cause it to go haywire on your files afterwards)
I suspect that this is actually the reason why there's a myth about corruption of the registry: With all of the redundancy, the registry is often the last component to fail when a drive succumbs. At the same time, Windows will refuse to start *if* the registry is corrupted. At that point the drive is in such a bad state, that even restoring/repairing the registry corruption will not save the drive.
Slashdot Mirror
Also note, very few people in Denmark uses electric heating as you can get hot water from centralized production into your home (not clean only for use in radiators). My parents gets their heating from a power plant 20km away.
Not to nitpick, but danes refer to that centralized production as "surplus heat". The "surplus" heat is heat generated as a bi-effect from producing electricity.... - from coal. So, when the electricity all comes from wind, the danes need to find some other way to heat their houses during winter.
How do prepared statements handle the not uncommon situation where you want to include an "in" clause? For example:
select * from customers where city in ?citylist
This was the problem they tried to solve by dynamically creating a statement like:
select * from customers where city in (?city-1, ?city-2, ?city-3)
So, to generate the -1, -2, and -3 parts they relied upon the index of the array.
Only in PHP an array will turn around and bite you with it's dual personality as a hash table. A hash table where one key was not "-1" but rathersomething like (pseudo):
-1); drop table students; --
You cannot really fault the Drupal developers for trying to support this commonly occurring pattern, for which there are no good solutions with plain prepared statements. After all, if they could write secure code for a common problem that could prevent less experienced developers for falling back to error-prone and insecure string interpolation.
Don't get me wrong: The drupal developers is at fault. But they were set up by the criminally insecure PHP.
Should be outright banned.
While the responsibility for this rests with Drupal, they were set up by another strange design decision of PHP: The fact that arrays are also hashtables and vice-versa. There are *tons* of these strange design decisions in PHP.
I'm sure we can do some stuff with signed repositories and signed packages to detect when things 'change' and/or keep unsigned repositories 'untrusted'.
Suggestion: For "trusted" repositories, toenable automatic updating, developers must sign the original install package with a certificate. Self-issued certs could be ok for this part. Any subsequent updates must be signed with the *same* certificate. If not, it will *not* automatically update - even if the repository is "trusted". OneGet clients will only allow auto-update if the product/vendor names are the same and the certificate public key is the same. Otherwise a warning should be issued and the local administrator should choose whether to trust the new cert going forward.
The installer should put abc.dll in the same directory as the .exe file instead of a shared location.
No!
If the DLL is indeed candidate for being shared (e.g. part of a shared product) it should put the assembly/DLL in the Global Assembly Cache (GAC). This is a side-by-side store where the same assembly/DLL can exist in multiple versions.
If security vulnerabilities are found and a patch is released, only the version in the GAC needs to be updated, often by registering a new version with a manifest/redirection that will ensure that anyone requesting the old (vulnerable) version will be treated to the new (fixed) version.
Windows Installer does this. And supports patching.
In Linux, I've had all kinds of dependency hell.
Yes, Linux never solved dependency hell, it has been swept under the rug that is distro+version specific repositories. The problem is still very, very real, but if you constrain yourself to the repositories of the distro + version that you use, the package maintainers will have ensured that the package dependencies do not conflict with each other and with the version of the ABI that your distro+version is on.
DLL hell was *very* real in the Windows 9x days. Side-by-side assemblies was introduced with Windows 98SE (IIRC) - but really only became de rigueur with Windows XP. During the 9x days, software developers took advantage of the fact that nothing prevented them from writing files to the system directories. When they encountered a problem where they needed a DLL - they simply installed it in the system directory - often overwriting whatever was there before. Obviously this caused all sorts of problems where only the latest installed product had a robust state.
https://en.wikipedia.org/wiki/...
Rather than leaving the dependency resolving responsibility to package maintainers, the Windows OS contains a brokering mechanism that will load the correct version of an assembly - even if multiple versions of the same assembly exists in the global assembly.
Linux package managers have dual responsibilities: Provide available software (with update mechanism) and ensure dependency hell does not rear its ugly head. Linux dependency hell is very real, once you step outside the repositories.
Windows has binary compatibility with software that was developed for Windows 95 / Windows NT 3.1 (where Win32 debuted). The dependency problem (called DLL hell in Windows) was solved with the SxS and the broader use of the Windows Installer package manager, which integrated with SxS.
Posting AC since I already moderated here.
After going to the Youtube page, I gotta say - Just what the fuck?
So now in order to salve the wounds of people butthurt by the monumental sucakge of Windows 8, will be treated to the awesome best ever spectacle of rotating menu items, what they've always been waiting for?
Ahem. The youtube link (showing the flipping menus) shows a Linux desktop. It was intended by submitter jonas-supa to show how much more advanced Linux desktops are.
Can't wait until the fanbois come out and tell us how waiting for a menu to spin around a few times is based on extensive research done by Microsoft that proves once and for all that most users want the operating system to waste their fucking time, and that anyone who doesn't just love the steaming hot piece of shit is an idiot who doesn't kow that they are doing.
Lol. We have to wait for the Linux fanbois to explain why the hell Linux needs compiz and all of the (agreed: Horrid!) animations from that youtube link.
Way to go there, buddy.
The new Microsoft Time Telling and Instant Notification Wrist Computer Ultimate Edition
The whole article is de-indexed. That is the only way it can work
What? Google already uses a huge directory of "stop words" - words or phrases that should not be indexed. What is required is that they can create such stop words per link (article). Maybe they are not done with that yet, but it could certainly work that way.
The goal is not to suppress articles, the goal is to protect individuals right to privacy. Google does not control the article, and they should not remove all links (associations) to articles. But they can and should respect individuals right to privacy. So when an association is outdated, irrelevant or misleading they should - upon request - remove the association - not the article, not all the other links to the article.
And yes - that includes the right to delete associations between your name and a possible crime you committed 30 years ago. Most modern judicial systems (US the notable exception) recognize that when you've done your time you have "paid" your debt to society - and should have a chance to start over. If youthful stupidities will follow you your entire live you will *never* get a chance to prove that you have corrected yourself.
And this is NOT just for criminals. Controversies, your participation in demonstrations, debates, political parties, deliberate smear campaigns etc. all have the potential to seriously inhibit your chances with future employers.
Was the article removed in its entirety, or was the *association* between the name and the article removed.
Of course Google should not remove the entire article. That was never what the law said. If they did so, it was just another blatant attempt at manipulating opinions of journalists in the hope that journalists reporting will start sway public opinion.
If it was just the *link* between a commentator name and the article that was removed, i.e. you would still find the article through googling words from the content of the article, then what is BBSs problem?
Google is blatantly trying to manipulate public opinion through journalists. They are deliberately misinterpreting the law to create an impression of draconian consequences.
People can write equally vulnerable code in Python or Java or Ruby.
Nonsensical. Yes, given enough effort, one can certainly write equally vulnerable code in Python or Java or Ruby. That does not prove *anything*
This particular vulnerability is directly triggered by a extremely poor PHP design decision: To conflate arrays and hashtables. The Drupal developers wrote some code that on the surface looks sorta ok. But it assumes that the passed array has numerical indexes.
But in their wisdom, PHP designers decided that separate data structures were too complex for programmers to understand. Alas, arrays as hashtables are the same, since one could view an array as "just" a hashtable that happens to use integers as keys.
The code in question assumed that it could retrieve the "position" of a value in the array and use that. Only, when the position was text with PHP or SQL attack code it led to a vulnerability.
There is NO way to compare that to vulnerabilities created by Python, Java or Ruby developers. Given the exact same lines of thought - which are not at all "out there" the same way of thinking woul NOT have led to a serious vulnerability in any of those languages.
PHP is just bad, bad design. And the bad design is dangerous.
It wasn't a bug in bash, it was working exactly as expected. What wasn't expected was web devs passing in data directly from the Internet into bash. Bash incorrectly assumed that environmental variables were assigned from a trusted source.
Nope. It was a bug. While it was the intention that bash would "import" function definitions from env vars, it was *never* the intention that it would directly and without confirmation execute any commands *following* the function definitions in the env vars.
So yes, a serious bug.
1 - ISight claims this has been a five year campaign and then add that "hackers began only in August to exploit a vulnerability found in most versions of Windows". So where did the "five year" timeline come from?
2 - "Russian hackers target NATO, Ukraine and others" the article screams and then we find this wishy washy explanation from ISight's John Hullquist on his claim about the hackers being Russian:
Sounds like a bunch of FUD to me
While I suspect that ISight (like all "security research" companies) deliberately stirs the pot (it helps generate awareness of their products), they do not actually claim that the specific vulnerability has been used for 5 years.
One could imagine that the "Sandworm" operation has been ongoing for 5 years. If they continually and persistently try to infiltrate NATO and other organizations they will probably use whatever opportunity presents itself. They actually also try to exploit vulnerabilities that have long been patched, hoping to hit an unpatched machine.
So while they do try to sensationalize, it is conceivable that the hacker group is older than just the most recently used vulnerability.
Why?
Microsoft is not a state-owned enterprise, and has no allegiance to any state. It has a responsibility only towards its shareholders, and apparently the business model of selling flawed software is very profitable.
As opposed to doling out flawed software for free?
does IIS pass headers along to CGI scripts the same way Apache does?
Are you fucking kidding? You get them out of a collection that's a property on the request object. They aren't shat into arbitrary fucking shell environment variables, like someone's freshman year CompSci project. Grow up!
I believe that it is the CGI specification that requires parameters to be passed as environment variables. So if you use CGI on IIS it should work the same way.
That would not trigger this issue, however, as it requires some script to expand the environment variable and it is not an automatic braindead expansion like in bash. The most common environment variables to be expanded %WINDIR%, %USERNAME% and the like. Not ever have I seen someone write %HTTP_USER_AGENT% or any other %HTTP_*% expansion. There's no systemic failure as with bash Shellshock.
But to be fair, it *does* look like an injection vector. Yes, GGP blatantly ignored that the claim I made was about PowerShell - not cmd.exe - but there seems to be an issue, and it just reinforces my point that shells (i.e. Windows shells included) that conflate text and instructions are error prone by default.
It is the exact same type of vulnerability that have existed in other weakly-typed shells since their inception. This is the reason why you should use -print0 with find before passing it to any other program: If you do not you risk that the filename is an injection attack.
The culprit is the idea that a shell is just some form of text interpreter that will interpret anything that is text. There is no semantic separation of "text" and "executable".
Unfortunately, this "code is just text" has become so entrenched in shell scripting that it is vulnerabilities waiting to happen. Process substitution, subshells etc all rely on this very property.
At least with PowerShell there is no such stupidity. In PowerShell you have to indicate specifically each time you want text interpreted and executed. PowerShell script block is a separate type (actually, a lambda) from text, integers, dates, decimals etc. The ease of how you pass executable content (script blocks) even over the network removes most reasons to interpret text as executable commands.
Or you could use what we've been using for the past 20-30 years that has been debugged, proven to work and not completely different to the rest of the world.
Like.... bash?
Does anyone really want "better localization" in terminals. My experience as a bilingual user from windows is that the less things are localized the better they work.
I have to agree that you usually experience fewer problems if you just run as english. I do the same. I should not be that way, however.
Making commands localized breaks script compatibility. (And that includes any output if that is parsed too.)
That is (one of) the problems actually solved (on Windows) by PowerShell: Typed parameters and strong typing eradicates such parsing bugs
For processes more than 2 days old:
ps | ? starttime | ? starttime -lt (get-date).adddays(-2)
It has gone to the point where I get the English version of Windows rather than one adapted to my native language.
Me too, but not because of the CLI; rather the sooner availability of service packs and tech previews. Also, I cannot stand the mingling of languages in dialog boxes where some text is provided by the OS and some by the application.
The localization of some of the folder names makes things break and the translation of GUI elements obfuscates the function and makes it so that one has to translate everything to English and back to realize what the function is, especially when the original translator used every synonym for "device" he could possibly find.
Getting there. Slowly.
Yeah and who exactly is this afflicted user? Right, normally apache or some other unprivileged user who has relatively little power though granted you don't even want unprivileged users logging in from the Internet
You are one setuid/SUID utility away from total system compromise. Even one such utility that invokes bash (or the default shell which is bash on Fedora and RH systems) and your box isn't yours any more.
Shellshock is *also* a privilege escalation vulnerability when exploited locally. Granted, you need to find such a setuid utility. But the utility does not need to be vulnerable by itself. It just needs to invoke the shell through system() or similar.
I would have no qualms about this practice if it were completely up front in it's entirety rather than have to read about it in a blog.
This is quote from the page where you agree to the terms of the preview program (this is the top text - the first you read):
Accept the Terms of Use and Privacy Statement
This should be the most boring step. Accept the Terms of Use and Privacy Statement and we can finish up your registration.
By accepting the Terms of Use and Privacy Statement, you agree that:
* The experimental and early prerelease software and services might not be fully tested.
* You might experience crashes, security vulnerabilities, data loss, or damage to your device.
* Your detailed usage and device data will automatically go to Microsoft and our partners to improve our products and services. See the Privacy Statement for more information.
* You will receive communications about the program and related promotions. Once you’ve joined the program, to stop receiving such communications you must leave the program.
Some of this stuff will probably just concern the free Technical Preview, but there's still a clear trend of Microsoft turning Windows into a datamining platform. It started with Windows 8 where they try to get the user to log into their own computer with a Microsoft account. It seems to be only getting worse.
In Windows 10 you can choose not to use a Microsoft account - just like with Windows 8.
On top op that, Windows 10 will allow corporations to federate their own AD - which means that you will get the device-sync features *without* creating a Microsoft account.
Tell me what larger corporation concerned about information control is going to accept anything close to that?
Don't install the preview version for production purposes then.
This is telemetry from the preview version. You explicitly accept the telemetry when you join the preview program.
If a larger corporation does not like that, even for testing purposes, then they can simply wait for the final (RTM) version.
What if someone who privately knows about the vulnerability gets the idea to exploit various installations of competitors (or even common users!) during the embargo period? Do you trust large enterprises not to misuse their knowledge to their own advantage?
A patch cannot be prepared "privately" without a number of people knowing about it: Developers, testers, reviewers, server admins etc. At each of the organizations that are privy to the predisclosure.
There are money to be made from that. To gain access to an exploitable vulnerability before a patch can be distributed broadly is a massive opportunity.
What if someone starts to sell off their knowledge to blackhatters?
What if someone sets up what looks like a legitimate business (a fake antimalware) and uses it primary to get inside info?
I know it is a database, and slightly optimized. "A few records" would not affect query time, especially if they were not in the query path.
What about a lot of records? And how about a lot of records that are in the query path?
It's a database. IIRC it uses B* trees. Search time is proportional to the logarithm of total number of records. Even "a lot" of records may not cause the height of the tree to increase. You generally need to *square* the number of records to double to search time.
At the same time, the registry hives are really, really robust. Windows keeps to redundant copies and even protects writes through the kernel transaction manager as well as the journal of the file system. Corruption is virtually impossible until the hard drive decays to a state where even the redundancy cannot make up for it anymore. Unlike text files, both metadata *and* data are guaranteed to either succeed in an atomic transaction.
(compare to the Unix way, where config files can be corrupted if the system/power fails during a write: File system do not guarantees *data* consistency for regular files, only *metadata* consistency, i.e. the fs guarantees that its internal structures will not cause it to go haywire on your files afterwards)
I suspect that this is actually the reason why there's a myth about corruption of the registry: With all of the redundancy, the registry is often the last component to fail when a drive succumbs. At the same time, Windows will refuse to start *if* the registry is corrupted. At that point the drive is in such a bad state, that even restoring/repairing the registry corruption will not save the drive.