1. Make more things modular. What about replacing batteries (yes, plural) for disk modules too, or wi-fy?
2. Use 1 quad-core CPU, turn 3 cores down when you are unplugged. Bonus point for an assyncrhonous quad-core CPU, that lets you turn the voltage down. What about turning some RAM down too? It will need a custom OS anyway.
3. Ok, pipe dream. But the keyboard can be composed of several mountable modules, so you can have a big one, while keeping the laptop small.
4. E-paper back would be very nice.
5. Yeah, that would be nice, or a A5 form for a more portable notebook (two different models).
"And if your exchange server is compromised and loads a DLL using its normal API for loading modules, then it can do anything that module will attack."
That's true, but as far as I can see, there is no reason that the same concept couldn't be applied to dynamic linking for most programs. The exception being the programs that construct library names at run-time, what should amount to 1 or 2 executables at an entire system.
Not too specialized, since running servers is a very common use of Linux. Also, all the overhead goes away if it is activated by a flag at compile time, like lots of other Linux functionalities.
Its biggest roadblocks seem to be the usual ones: very recent code that may have bugs, no maintence history (the Linux developers may want to wait a bit more to see if they won't get a bomb), politics...
Ok, I have no mod opints here, but please, somebody mod the paent up. In lay-man words, he has just explained how this experiment doesn't prove time travel is possible (wht the summary leads one to wrongly think it does).
That is a big chain of "if"s. Also, life doesn't seem to care about slow evolution here on Eath. It moves slowly when things are ok, and fast when they aren't. If something, I'd be concerned about a big mutation rate, not small.
Doesn't look like a "woosh". I guess the GP is simply talking about another factor (but didn't care to give a frame of reference). Anyway, I'd ignore any aether based jokes.
I also tought about the Milkway's core after I readed somebody talking about dark matter, but this graph
(from another previous poster) shows peak activity after the aphelion, not before it.
Ok, I find it hard to belive that they used a dirt power system as clock, just because the errors are so small. But could the distance from the Sun (the neutrino intensity) influence the detector?
Well, temperature may influence it somehow, but not in a direct way. First, nuclear reactions are very different from chemical ones. Fission even happens on single atoms, without interactions, so the main contribution of temperatre does not influence it.
Also, people have created nuclear reactions on several different temperatures, from liquid helium to the cores of nuclear reactors and nuclear weapon explosions. Up to now, there is no notice of them disagreeing with the theory.
There is no problem on it not being temporary. In fact, it is better that the browser remember the certificate, so it can warn if it changes.
The problem here is that you have two options:
Trust the cert. So Firefox will access the site with all the configurations of a trusted site, including changing the warning and cookie permissions like it had a valid certificate.
Don't trust the cert. So firefox won't access the site.
There is a big hole here, for a site that you don't trust (like any other plain HTTP site at the web), but want to see anyway.
Firefox could do all kind of nice things if it accepted self signed certificates like plain HTTP, like expiring cookies if the cert changes. The developers only need to change their mindset from thinking that "the user thinks a HTTPS page is secure" to "the user belives Firefox when it tells that a page is secure". The browser should never tell that a page with a self signed certificate is secure (unless it is accepted), but it shouldn't tell that it is insecure either (unless it is configured to tell HTTP pages insecure).
So don't tell the user that the link is secure. That is a matter of expectation, if the browser didn't show a yellow address bar and the lock for (not accepted) self signed certs, and used all the warnings and other configuration that applies to plain HTTP, there would be no expectation of security.
But, instead, Mozilla choosed to fool their users into thinking that plain HTTP is more secure than self signed certificates.
You can have free applications on the client too, see, no need for web apps to solve that problem.
Also, current web apps are an order of magnitude worse than current locked client side apps, they lock your data (in the 'you can't put your hands at it'), while client side apps just lock the format of the data, so you can still reverse engineer it.
I said it on a previous post, but I'll repeat it here. If you have a licencing problem, go negotiate another licence (free or not). Migrating to the web won't solve the problem.
Or, maybe, we can have some programs that run localy to the client, they can send files throug the net if needed. I know it is a new, untested idea, but makes some sense to me.
What is really annoying is that distributing ECMAScript apps over the web is a solution to a legal problem (licencing), not a technical one, that a few players decided to create and could be solved by several ways (one of them being free software, but there are others). Now everybody is strugling to reinvent lots and lots of weels just because of that.
Slashdot Mirror
No problem, your sig excuses you.
Yep. You are right. That also includes Apache, LightHttpd, PostgreSQL, Exim and others.
If I just had the money to produce it...
1. Make more things modular. What about replacing batteries (yes, plural) for disk modules too, or wi-fy?
2. Use 1 quad-core CPU, turn 3 cores down when you are unplugged. Bonus point for an assyncrhonous quad-core CPU, that lets you turn the voltage down. What about turning some RAM down too? It will need a custom OS anyway.
3. Ok, pipe dream. But the keyboard can be composed of several mountable modules, so you can have a big one, while keeping the laptop small.
4. E-paper back would be very nice.
5. Yeah, that would be nice, or a A5 form for a more portable notebook (two different models).
6. That's interesting.
6 (again). That is very interesting :)
That's true, but as far as I can see, there is no reason that the same concept couldn't be applied to dynamic linking for most programs. The exception being the programs that construct library names at run-time, what should amount to 1 or 2 executables at an entire system.
Not too specialized, since running servers is a very common use of Linux. Also, all the overhead goes away if it is activated by a flag at compile time, like lots of other Linux functionalities.
Its biggest roadblocks seem to be the usual ones: very recent code that may have bugs, no maintence history (the Linux developers may want to wait a bit more to see if they won't get a bomb), politics...
That is the second time I see someone complaining that it won't work on scripts, and the parent is a very well constructed answer to that.
That does not suck. But the alternative...
Ok, I've made a LHC black hole joke. I couldn't resist... Shame on me :(
Ok, I have no mod opints here, but please, somebody mod the paent up. In lay-man words, he has just explained how this experiment doesn't prove time travel is possible (wht the summary leads one to wrongly think it does).
There is no reason for that not working. And, except for the cable and the asteroid, we already have all the needed equipment ;)
Man, I'd mod you up. So bad my mod points timed-out earlier this week.
Some 5% or less.
I guess some 50% to 70%.
There is some other 25% to 45%.
That is the only easy one. for that I am absolutely sure it is exactly 0%. Nobody not infringe copyright laws. Not the way they are written today.
Everything is exposed to the OS, not just IPC.
That is a big chain of "if"s. Also, life doesn't seem to care about slow evolution here on Eath. It moves slowly when things are ok, and fast when they aren't. If something, I'd be concerned about a big mutation rate, not small.
Doesn't look like a "woosh". I guess the GP is simply talking about another factor (but didn't care to give a frame of reference). Anyway, I'd ignore any aether based jokes.
I also tought about the Milkway's core after I readed somebody talking about dark matter, but this graph (from another previous poster) shows peak activity after the aphelion, not before it.
Ok, I find it hard to belive that they used a dirt power system as clock, just because the errors are so small. But could the distance from the Sun (the neutrino intensity) influence the detector?
Well, temperature may influence it somehow, but not in a direct way. First, nuclear reactions are very different from chemical ones. Fission even happens on single atoms, without interactions, so the main contribution of temperatre does not influence it.
Also, people have created nuclear reactions on several different temperatures, from liquid helium to the cores of nuclear reactors and nuclear weapon explosions. Up to now, there is no notice of them disagreeing with the theory.
There is no problem on it not being temporary. In fact, it is better that the browser remember the certificate, so it can warn if it changes.
The problem here is that you have two options:
There is a big hole here, for a site that you don't trust (like any other plain HTTP site at the web), but want to see anyway.
Firefox could do all kind of nice things if it accepted self signed certificates like plain HTTP, like expiring cookies if the cert changes. The developers only need to change their mindset from thinking that "the user thinks a HTTPS page is secure" to "the user belives Firefox when it tells that a page is secure". The browser should never tell that a page with a self signed certificate is secure (unless it is accepted), but it shouldn't tell that it is insecure either (unless it is configured to tell HTTP pages insecure).
The site makes no claim about security. It is Firefox that is claiming it secure or insecure all the time.
Why can't Firefox just not claim anything, like it does to normal HTTP?
So don't tell the user that the link is secure. That is a matter of expectation, if the browser didn't show a yellow address bar and the lock for (not accepted) self signed certs, and used all the warnings and other configuration that applies to plain HTTP, there would be no expectation of security.
But, instead, Mozilla choosed to fool their users into thinking that plain HTTP is more secure than self signed certificates.
Maybe you could read the parent. He explains his point clearly.
Ok, not by that margin, but Java Script is still worse.
You can have free applications on the client too, see, no need for web apps to solve that problem.
Also, current web apps are an order of magnitude worse than current locked client side apps, they lock your data (in the 'you can't put your hands at it'), while client side apps just lock the format of the data, so you can still reverse engineer it.
I said it on a previous post, but I'll repeat it here. If you have a licencing problem, go negotiate another licence (free or not). Migrating to the web won't solve the problem.
Or, maybe, we can have some programs that run localy to the client, they can send files throug the net if needed. I know it is a new, untested idea, but makes some sense to me.
What is really annoying is that distributing ECMAScript apps over the web is a solution to a legal problem (licencing), not a technical one, that a few players decided to create and could be solved by several ways (one of them being free software, but there are others). Now everybody is strugling to reinvent lots and lots of weels just because of that.
I stand corrected. I also don't know Novell's support, so no reason to complain ;)
"So far as I know the only people in Gitmo are those who tried to kill us or support those trying to kill us."
When the Executive reaches that conclusion alone, you can never be sure.