We are approaching the point where it does not make sense to upgrade RAM. Right now you often only get 256MB per memory chip, and it takes 4 chips to fill a typical bus (x16), so the minimum amount of memory you can sensibly install is 1GB. Obviously you can go with older 128MB or lower chips, but they are not much cheaper. Already you can do 512MB per chip, and with DDR4 we will likely hit 1GB per chip. We are not many chip generations away from being able to satisfy the needs of most users with a few soldered-in chips, which will help latency a lot.
Allow a single site to have either multiple certificates or multiple signatures from different providers. This means that important sites could be signed by e.g. both Verisign and Globalsign, so it would be possible for users to remove trust of a provider without losing the TLS protection. Without this, there will never be a free market for certificates and browser makers will have to include root certificates from even the least trustable providers, so it simply HAS to happen. Fortunately it is relatively easy to implement.
For extra points, implement support for off-site certificate stores so third parties can attest to the validity of a particular key. Groups of users could collaborate to verify the certificates of sites, which could create a level of protection against fraudulent certificates from the primary providers. This proposal is much harder to implement securely.
Even if you do have an environment where the web server is running as the user account, such as php safe mode, or ruby on rails with a passenger phusion server, that prohibits you from having different login credentials for different apps.
It seems to me that keeping passwords around in files is security through obscurity. Sure, each app gets its own credentials, but if one app running as a particular user can access a specific database by reading a password from a file, then so can the other apps...
I keep hearing that Postgres is hard to admin. Yet Postgres integrates with the normal Unix user accounts so I don't have to worry about users and passwords, it uses sockets by default so I don't have to worry about networking (unless the SQL server is remote), it provides sane semantics without having to worry about table types...
I like SHOW CREATE TABLE from MySQL and the \-commands could use some aliases, but other than that Postgres is rather nice to admin and use.
Comodo's entire SSL business is built around letting dodgy affiliates generate certificates. They're the only ones (AFAIK) doing it that way. It will fail again.
I don't know anything about their other products and I don't use Chrome either.
Somebody on NPR (the closest thing we have to BBC or CBC) stated that the manifesto was 1500 pages in length. Holy crap! I couldn't do 1500 pages for a doctorate!
Note also how Abigail R. Esman consistently uses the word "assimilate" rather than "integrate". She and her ilk won't be happy until she is unable to detect that someone has ties to cultures which did not develop in Western Europe. And when that is finally achieved, the crescent moon armbands will be brought in.
The original deal and its extension are the only cases I know where someone has said "You're violating my patents. Here, have $300 million and let that be a lesson for you!"
Yes, the US messes with nuclear-armed nations, but with the promise to let the dictators stay in power. Having nuclear weapons saves the dictators from the fate of Saddam Hussein. Nuclear weapons are not much help for democratic leaders who happen to be anti-US.
You don't want it going over the encrypted-by-default standard
You can't realistically do a bluetooth pairing every time you need to pay for something. Encryption is nothing without authentication, and the authentication problem cannot be solved.
For payments you need end-to-end encryption, and then it doesn't matter whether the wireless link itself is encrypted.
If I'm not imposing these changes on other users, what's the advantage of doing it this way over simply sharing things in my home directory?
You can install the software you want where you want it, you make/usr/bin/emacs run ed, you change anything you want. If you want to, you can let other users see/adopt your cool directory layout and all the fantastic software you installed (they just have to be prepared to
We'll probably never see this functionality used much; that boat has sailed. It is difficult to say which innovative uses that people would have come up with for such a flexible system. Perhaps you are right and no one would have found uses for it.
Doing stuff like that which affects other users should require admin rights
I think this sentence is where most of your objections come from. The trick is that it doesn't affect other users, unless you specifically allow them to look in your view of the file system. FUSE is much more limited and it would be difficult e.g. to put the root file system on FUSE.
HURD was designed when multi-user systems with remote file systems were the norm. Today a lot of the features seem superfluous -- approximately no one has multiple concurrent users on their phone and remote file systems have been replaced by HTTP requests. Getting rid of the SUID-bit and making it possible for users to present limited environments to the less-trusted programs they run still make sense.
The only fundamental technical difference of note I see is that it's got a microkernel
HURD is about empowering the users to do things which require root access on more common systems. Like you have a normal user account and decide you want to try this cool new network file system but the admin won't install the kernel module. On HURD, not a problem, you just run a file system daemon yourself and you can mount it anywhere you want without needing administrator rights.
Or you decide that package managers suck and it's much better to keep all files for Emacs in/Applications/Emacs (Or/OS/Emacs for the purists). At the same time you want the files available in their usual locations like/usr/bin/emacs so the normal path handling works, but you want all the files to disappear when you do rm -r/Applications/Emacs. Not a problem in HURD. Basically you have the full power of a Unix administrator/developer without needing root.
Now, that was the kind of features which were discussed for HURD in the 90's. I have never actually tried HURD, so don't be too disappointed if it didn't all materialize.
One reason for the occasional freezes on the linux version is due to the SQLite RDBMS which is used to store a bunch of stuff that belongs in straight text files. Don't blame the people that wrote SQLite. A real RDBMS is supposed to do stuff like fsync() to commit transactions and ensure database integrity. Then again, an RDBMS is usually intended to be run on a dedicated server, not as part of the infrastructure of a stinking web browser.
It isn't sqlite's fault that the current implementations of ext3 and ext4 are completely useless at fsync(). Also, it really doesn't make sense to run SQLite on a dedicated server. SQLite is for when you need a handy easy-to-use database with real ACID properties but not an entire database server.
I wish they would do 5 NiMH cells shaped like 4 AA batteries in the most common configuration. There are quite a few things which require 4 AA batteries but only runs briefly or not at all on 4.8V. Obviously joined-up batteries wouldn't fit in every device, but it would help in some of them.
Alternatively, device makers should add a 5th battery slot for NiMH batteries, but that would require people to be sensible or device makers to add protective circuitry. Neither seems likely.
You can't do a first strike with ICBM's anymore. Not on anyone you would care to go nuclear on anyway. They would know within a few minutes of your launches. The point of stealth planes is that they could be on target BEFORE the enemy realizes they are at war. It does not matter so much that they took 2 hours to get there.
If you want to use planes for retaliation, you need to have them in the air pretty much constantly and have the crew able to actually arm and fire them (otherwise you are dependent on a command structure which may no longer exist when needed). That is a lot of trust to put in a crew of two, and crashes of nuclear-armed planes have historically caused embarrassment. Submarines are superior.
2500 is not a small arsenal when it is far more than all non-Russian non-US bombs put together. Russia has traditionally been eager to participate in START.
Is it really still necessary to be able to threaten a nuclear first strike? The US seems to be more than capable of holding off any conventional threat without having to go nuclear.
If you are designing bombers for delivering nuclear weapons today, you are talking stealth bombers like the B2 so you can launch a first strike. For non-stealth attacks, missiles are much cheaper.
The B2 is fairly useless for conventional warfare because you can never build enough of them to REALLY harm Russia or China with conventional weapons. If you want to hit someone smaller than that, you can usually make do with the much smaller payload of the F22 for surgical strikes, or (the most favoured option lately) simply beat their air defences to a pulp.
The only point of minimizing civilian casualties from nuclear strikes is to make it politically feasible to once again use nukes for a first strike. Hopefully that will never come to pass.
Slashdot Mirror
Why not allow wheels then? 100m should easily be possible in 2s, and much faster if you get rid of the useless "runner".
You're pretty much describing Formula 1 in the 80's. Calling it "running" seems to be a bit of a stretch though.
We are approaching the point where it does not make sense to upgrade RAM. Right now you often only get 256MB per memory chip, and it takes 4 chips to fill a typical bus (x16), so the minimum amount of memory you can sensibly install is 1GB. Obviously you can go with older 128MB or lower chips, but they are not much cheaper. Already you can do 512MB per chip, and with DDR4 we will likely hit 1GB per chip. We are not many chip generations away from being able to satisfy the needs of most users with a few soldered-in chips, which will help latency a lot.
The market has pretty much given up on the ratings companies and many market participants now do their own rating.
If I don't trust the CA I can't build a secure TLS connection. A man-in-the-middle is trivial.
Allow a single site to have either multiple certificates or multiple signatures from different providers. This means that important sites could be signed by e.g. both Verisign and Globalsign, so it would be possible for users to remove trust of a provider without losing the TLS protection. Without this, there will never be a free market for certificates and browser makers will have to include root certificates from even the least trustable providers, so it simply HAS to happen. Fortunately it is relatively easy to implement.
For extra points, implement support for off-site certificate stores so third parties can attest to the validity of a particular key. Groups of users could collaborate to verify the certificates of sites, which could create a level of protection against fraudulent certificates from the primary providers. This proposal is much harder to implement securely.
Even if you do have an environment where the web server is running as the user account, such as php safe mode, or ruby on rails with a passenger phusion server, that prohibits you from having different login credentials for different apps.
It seems to me that keeping passwords around in files is security through obscurity. Sure, each app gets its own credentials, but if one app running as a particular user can access a specific database by reading a password from a file, then so can the other apps...
I keep hearing that Postgres is hard to admin. Yet Postgres integrates with the normal Unix user accounts so I don't have to worry about users and passwords, it uses sockets by default so I don't have to worry about networking (unless the SQL server is remote), it provides sane semantics without having to worry about table types...
I like SHOW CREATE TABLE from MySQL and the \-commands could use some aliases, but other than that Postgres is rather nice to admin and use.
As it currently exists, if we were to take 100% of the income from every American today, it would not pay off the national debt.
Unit error. Debt is in USD, income is in USD/s. As a Slashdot user you should know better, even if many economists don't.
Comodo's entire SSL business is built around letting dodgy affiliates generate certificates. They're the only ones (AFAIK) doing it that way. It will fail again.
I don't know anything about their other products and I don't use Chrome either.
Comodo IS the dodgy SSL provider. They have a worse record than Verisign, which takes some doing.
Somebody on NPR (the closest thing we have to BBC or CBC) stated that the manifesto was 1500 pages in length. Holy crap! I couldn't do 1500 pages for a doctorate!
A lot of it was copied.
Note also how Abigail R. Esman consistently uses the word "assimilate" rather than "integrate". She and her ilk won't be happy until she is unable to detect that someone has ties to cultures which did not develop in Western Europe. And when that is finally achieved, the crescent moon armbands will be brought in.
The original deal and its extension are the only cases I know where someone has said "You're violating my patents. Here, have $300 million and let that be a lesson for you!"
Yes, the US messes with nuclear-armed nations, but with the promise to let the dictators stay in power. Having nuclear weapons saves the dictators from the fate of Saddam Hussein. Nuclear weapons are not much help for democratic leaders who happen to be anti-US.
You don't want it going over the encrypted-by-default standard
You can't realistically do a bluetooth pairing every time you need to pay for something. Encryption is nothing without authentication, and the authentication problem cannot be solved.
For payments you need end-to-end encryption, and then it doesn't matter whether the wireless link itself is encrypted.
If I'm not imposing these changes on other users, what's the advantage of doing it this way over simply sharing things in my home directory?
You can install the software you want where you want it, you make /usr/bin/emacs run ed, you change anything you want. If you want to, you can let other users see/adopt your cool directory layout and all the fantastic software you installed (they just have to be prepared to
We'll probably never see this functionality used much; that boat has sailed. It is difficult to say which innovative uses that people would have come up with for such a flexible system. Perhaps you are right and no one would have found uses for it.
Doing stuff like that which affects other users should require admin rights
I think this sentence is where most of your objections come from. The trick is that it doesn't affect other users, unless you specifically allow them to look in your view of the file system. FUSE is much more limited and it would be difficult e.g. to put the root file system on FUSE.
HURD was designed when multi-user systems with remote file systems were the norm. Today a lot of the features seem superfluous -- approximately no one has multiple concurrent users on their phone and remote file systems have been replaced by HTTP requests. Getting rid of the SUID-bit and making it possible for users to present limited environments to the less-trusted programs they run still make sense.
The only fundamental technical difference of note I see is that it's got a microkernel
HURD is about empowering the users to do things which require root access on more common systems. Like you have a normal user account and decide you want to try this cool new network file system but the admin won't install the kernel module. On HURD, not a problem, you just run a file system daemon yourself and you can mount it anywhere you want without needing administrator rights.
Or you decide that package managers suck and it's much better to keep all files for Emacs in /Applications/Emacs (Or /OS/Emacs for the purists). At the same time you want the files available in their usual locations like /usr/bin/emacs so the normal path handling works, but you want all the files to disappear when you do rm -r /Applications/Emacs. Not a problem in HURD. Basically you have the full power of a Unix administrator/developer without needing root.
Now, that was the kind of features which were discussed for HURD in the 90's. I have never actually tried HURD, so don't be too disappointed if it didn't all materialize.
One reason for the occasional freezes on the linux version is due to the SQLite RDBMS which is used to store a bunch of stuff that belongs in straight text files. Don't blame the people that wrote SQLite. A real RDBMS is supposed to do stuff like fsync() to commit transactions and ensure database integrity. Then again, an RDBMS is usually intended to be run on a dedicated server, not as part of the infrastructure of a stinking web browser.
It isn't sqlite's fault that the current implementations of ext3 and ext4 are completely useless at fsync(). Also, it really doesn't make sense to run SQLite on a dedicated server. SQLite is for when you need a handy easy-to-use database with real ACID properties but not an entire database server.
I wish they would do 5 NiMH cells shaped like 4 AA batteries in the most common configuration. There are quite a few things which require 4 AA batteries but only runs briefly or not at all on 4.8V. Obviously joined-up batteries wouldn't fit in every device, but it would help in some of them.
Alternatively, device makers should add a 5th battery slot for NiMH batteries, but that would require people to be sensible or device makers to add protective circuitry. Neither seems likely.
You can't do a first strike with ICBM's anymore. Not on anyone you would care to go nuclear on anyway. They would know within a few minutes of your launches. The point of stealth planes is that they could be on target BEFORE the enemy realizes they are at war. It does not matter so much that they took 2 hours to get there.
If you want to use planes for retaliation, you need to have them in the air pretty much constantly and have the crew able to actually arm and fire them (otherwise you are dependent on a command structure which may no longer exist when needed). That is a lot of trust to put in a crew of two, and crashes of nuclear-armed planes have historically caused embarrassment. Submarines are superior.
2500 is not a small arsenal when it is far more than all non-Russian non-US bombs put together. Russia has traditionally been eager to participate in START.
Is it really still necessary to be able to threaten a nuclear first strike? The US seems to be more than capable of holding off any conventional threat without having to go nuclear.
If you are designing bombers for delivering nuclear weapons today, you are talking stealth bombers like the B2 so you can launch a first strike. For non-stealth attacks, missiles are much cheaper.
The B2 is fairly useless for conventional warfare because you can never build enough of them to REALLY harm Russia or China with conventional weapons. If you want to hit someone smaller than that, you can usually make do with the much smaller payload of the F22 for surgical strikes, or (the most favoured option lately) simply beat their air defences to a pulp.
For boomers the picture is even clearer.
Tactical nukes aren't defensive weapons. Strategic nukes are.
The only point of minimizing civilian casualties from nuclear strikes is to make it politically feasible to once again use nukes for a first strike. Hopefully that will never come to pass.