So in the future we will not release rpm packages and setup files but VM images to our customers? Ok, why not. It could ease deployment of highly customizable enterprise software. So you basically deploy all the OS config with it. Sounds cool. No more telling the sysadmin to open ports, create mount points, set permissions, install init scripts, update this and that library, etc.
This only stops the most primitive incarnation of fork bombs like:(){:|:& };: whose processes don't die. While you can set limits to the max. number of processes per user, there is AFAIK no limit to the number of processes I can create per second. So as long as my processes are short lived nothing stops me from creating 1000 processes per second. Don't try this at home on a 2.4 kernel, kids.
It's a nice move of Apple, because it eases cross browser tests. Web designers using a PC don't have to switch to a Mac to test their site on Safari anymore. They can test under Windows. Of course fonts are different under OS X, so at some point you will HAVE to test the site on OS X. But for everyday use its nice to have Safari for the Windows platform.
Strangely enough that encourages web designers to use Windows as their developement platform of choice. Because on OS X there is no IE...
1./deleteAccount displays a confirmation form that contains a generated token value in a hidden field 2. User submits the form to/deleteAccount including the token 3. Server validates if token matches the handed out value
An external site would have to hijack the session cookie to forge such a request. But then it could do anything anyway.
Whether the software has bug is obviously out of question. It's more interesting to see how often you encounter a severe bug in a product. This should actually become a metric for any software. Something like MTBC: Mean Time Between Crash. Someone ring Gartner:-)
Windows user: - Google for the problem - Modify registry according to some forum posting - Download some tool that promises to fix the problem - Install the tool (along with tons of malware) - Ask friend - Friend reinstalls Windows - User is happy
Linux user: - Read man pages - Google for the problem - Read forums/wikis - Analyze problem and find exact cause - Edit some text files - User is happy
Linx users require different problem solving skills. These skills are comparatively "high" like engineering skills. Not something the average user is likely to have.
Also if a "switcher" tries the Windows problem solving algorithm with Linux it won't work.
Of course it's easier to create innovative features by writing spaghetti code that circumvents well-defined (and limited) interfaces. But it makes the codebase harder to maintain! The spaghetti code will break more likely than code that goes through the interfaces and adheres to the contract. Layer violations are a strong indicator that the current interfaces are not flexible enough or that they are too high-level. But the longterm solution is cerainly not spaghetti code.
If the FBI denies its existance and you are not to speak about it, you can just silently throw it in the bin and forget about it, right? I mean they can't possibly sue you over something that doesn't even legally exist. Okay, maybe in a country like your they can.
...same researchers found that their Ubermosquito had developed a capability of transmitting AIDS now. That was an en even worse disappointment than when Malaria had developed a resistence and was spreading as before...
And: Ask our Australian friends about what people thought when they released a new species into their country versus what happened really. And scientists really claim they understand ecosystems? That's what I call dangerous.
And despite the fact that IPsec was developed for IPv6 or at least with IPv6 in mind, it also works with IPv4. All in all, IPsec can't be considered a security advantage for IPv6.
IPSec over IPv4 always uses UDP as a transport layer. This poses big problems for NAT devices. Breaking IPSec connections are a daily nuissance. IPSec is embedded naturally within IPv6 and is independent of the transport layer. With that even opportunistic encryption can be done. These two facts are a huge advantage over IPv4!
HTTP offers several standard headers to be interpreted by caches. The question is, does Google honour the instructions in those headers? On the other hand, content providers that serve content sensitive to cache problems are encouraged to correctly use those headers. Unfortunately (some/most?) content management systems do not provide means to control those.
Why would they do this? For security probably. On Unix programmers are (should be) aware of the fact that any file can possibly by a symlink. Especially processes with higher privileges must check if a filename that is passed to them as user input is a symlink to a file that is not normally under control of that user. So introducing this feature and running code that isn't symlink safe introduces a security risk.
So if a prof wants to use the MS kernel for his lectures, he first needs to convince his university to license this beast. The Windows kernel is not exactly a small code base. To understand it the prof then needs to look at it for, say, a year before he can give any reasonable lecture. It's a high risk for the prof because he doesn't know what the kernel will look like and if it will be useful for him. Sorry, things just don't work that way.
> Also, portage only gives you a default configuration file. You have to make (and test) any configuration file changes yourself.
That's totally on purpose! You don't want any package manager to mess with your config. When was the last time SuSE overwrote the httpd.conf with a default version? Okay, with major releases it is a bit tedious to upgrade to a new config file format. But any ebuild is free to provide an automatically updated config file for you, which you can accept, merge or reject with etc-update. It's just not common practice.
Slashdot Mirror
Start using IPv6 and you get oportunistic encryption (of IPsec) automatically (look ma, no config) on the IP level.
So in the future we will not release rpm packages and setup files but VM images to our customers? Ok, why not. It could ease deployment of highly customizable enterprise software. So you basically deploy all the OS config with it. Sounds cool. No more telling the sysadmin to open ports, create mount points, set permissions, install init scripts, update this and that library, etc.
This only stops the most primitive incarnation of fork bombs like :(){ :|:& };: whose processes don't die. While you can set limits to the max. number of processes per user, there is AFAIK no limit to the number of processes I can create per second. So as long as my processes are short lived nothing stops me from creating 1000 processes per second. Don't try this at home on a 2.4 kernel, kids.
Still thread creation can kill you. Renicing a fork bomb won't give you more cycles for your shell.
Traditionally email wraps even at 72 characters! Improves legibiltiy I guess.
Intel has released an errata document.
For June 2007 it lists 3 new errata:
AH106
A memory access may get a wrong memory type following a #GP due to WRMSR to an MTRR mask.
AH107
PMI while LBR freeze enabled may result in old/out-of-date LBR information
AH5P
VTPR may lead to a system hang
However, the document states that there are no fixes available. So it's probably not what MS/Intel is addressing here.
Okay, that's definitely cool! (If insane from a software engineer's point of view)
It's a nice move of Apple, because it eases cross browser tests. Web designers using a PC don't have to switch to a Mac to test their site on Safari anymore. They can test under Windows. Of course fonts are different under OS X, so at some point you will HAVE to test the site on OS X. But for everyday use its nice to have Safari for the Windows platform.
Strangely enough that encourages web designers to use Windows as their developement platform of choice. Because on OS X there is no IE...
Did you just say "doesn't taste as good"? Wouldn't that imply to FEED ON DEAD PEOPLE? I rather stick with propylene glycol, to be honest :-)
This is easily prevented by using request tokens.
/deleteAccount displays a confirmation form that contains a generated token value in a hidden field /deleteAccount including the token
1.
2. User submits the form to
3. Server validates if token matches the handed out value
An external site would have to hijack the session cookie to forge such a request. But then it could do anything anyway.
I prefer git for versioning on a local directory.
Whether the software has bug is obviously out of question. It's more interesting to see how often you encounter a severe bug in a product. This should actually become a metric for any software. Something like MTBC: Mean Time Between Crash. Someone ring Gartner :-)
Sorry, I couldn't find the article in that chaos of ads and popups.
Windows user:
- Google for the problem
- Modify registry according to some forum posting
- Download some tool that promises to fix the problem
- Install the tool (along with tons of malware)
- Ask friend
- Friend reinstalls Windows
- User is happy
Linux user:
- Read man pages
- Google for the problem
- Read forums/wikis
- Analyze problem and find exact cause
- Edit some text files
- User is happy
Linx users require different problem solving skills. These skills are comparatively "high" like engineering skills. Not something the average user is likely to have.
Also if a "switcher" tries the Windows problem solving algorithm with Linux it won't work.
No, they don't WANT an operating system. Most users don't even know what an OS is!
- Oh, so you are using Linux?
A what?
Operating System?
Is that something like another Word?
- err... never mind...
I already see the "related" Google ads:
* scintillators fix your mortgage
* Viagra particles
* free teen bosons
Uh... so they're making Solaris GPL, to be able to use Linux code :-) how cool!
Of course it's easier to create innovative features by writing spaghetti code that circumvents well-defined (and limited) interfaces. But it makes the codebase harder to maintain! The spaghetti code will break more likely than code that goes through the interfaces and adheres to the contract. Layer violations are a strong indicator that the current interfaces are not flexible enough or that they are too high-level. But the longterm solution is cerainly not spaghetti code.
If the FBI denies its existance and you are not to speak about it, you can just silently throw it in the bin and forget about it, right? I mean they can't possibly sue you over something that doesn't even legally exist. Okay, maybe in a country like your they can.
...same researchers found that their Ubermosquito had developed a capability of transmitting AIDS now. That was an en even worse disappointment than when Malaria had developed a resistence and was spreading as before...
And: Ask our Australian friends about what people thought when they released a new species into their country versus what happened really. And scientists really claim they understand ecosystems? That's what I call dangerous.
And despite the fact that IPsec was developed for IPv6 or at least with IPv6 in mind, it also works with IPv4. All in all, IPsec can't be considered a security advantage for IPv6.
IPSec over IPv4 always uses UDP as a transport layer. This poses big problems for NAT devices. Breaking IPSec connections are a daily nuissance. IPSec is embedded naturally within IPv6 and is independent of the transport layer. With that even opportunistic encryption can be done. These two facts are a huge advantage over IPv4!
HTTP offers several standard headers to be interpreted by caches. The question is, does Google honour the instructions in those headers? On the other hand, content providers that serve content sensitive to cache problems are encouraged to correctly use those headers. Unfortunately (some/most?) content management systems do not provide means to control those.
Why would they do this?
For security probably. On Unix programmers are (should be) aware of the fact that any file can possibly by a symlink. Especially processes with higher privileges must check if a filename that is passed to them as user input is a symlink to a file that is not normally under control of that user. So introducing this feature and running code that isn't symlink safe introduces a security risk.
So if a prof wants to use the MS kernel for his lectures, he first needs to convince his university to license this beast. The Windows kernel is not exactly a small code base. To understand it the prof then needs to look at it for, say, a year before he can give any reasonable lecture. It's a high risk for the prof because he doesn't know what the kernel will look like and if it will be useful for him. Sorry, things just don't work that way.
> Also, portage only gives you a default configuration file. You have to make (and test) any configuration file changes yourself.
That's totally on purpose! You don't want any package manager to mess with your config. When was the last time SuSE overwrote the httpd.conf with a default version? Okay, with major releases it is a bit tedious to upgrade to a new config file format. But any ebuild is free to provide an automatically updated config file for you, which you can accept, merge or reject with etc-update. It's just not common practice.