megalo != mega. megalo, according to m-w.com, means "of giant size", "grandiose" (e.g. megalomania).
Re: "you only need to boot it up once"
on
Booting Linux Faster
·
· Score: 4, Informative
I'm afraid that if you have a laptop, boot time is quite important. Doing suspend/resume with X running is not reliable. While I certainly agree that fixing this is the long term solution, a quicker boot-up is a reasonable fix in the meanwhile
There's a big difference though - the commercial version does not cost per device you sell (as opposed to WinCE).
Furthermore, you don't *need* the commercial version - that's how the Zaurii replacement ROMs were built in the first place. Furthermore, for a new device I'd expect a lot more work to be required in the kernel than in the user interface.
Since Flash is so cheap these days, it would have been better (IMHO) to have the home filesystem on flash and not within RAM, just like recent Zaurii. I don't know a single person who hasn't lost PDA data because of battery...
The Raven.
The difference is that the mobile phone signal is much, much stronger. Using a mobile phone near a radio will give you an idea (and you'll see why their usage is always prohibited on airliners, as oposed to other electronic devices, which are allowed after takeoff)
The only good thing about such patents is that they expire in 20 years, and you only have 1 year after you publish the idea to apply for a patent. So ancient stuff is fortunately rulled out.
Their deal is particularly appealing to those who purchased tkc software for 5500 devices (and since theKompany is the most significant Zaurus software vendor, there are quite a few) - they'll give you C7x0 versions of the apps that you bought from them for free.
It's not going to come from 64 vs. 32 bit as much as from the 8 extra general purpose registers (GPRs). With 8 registers (x86 architecture) you can do very little register allocation, and consequently have to go to memory almost every time you do an operation. +8 registers changes this significantly.
The register file is very fast to access and also has a fixed cost, whereas a memory operation can take a couple of hundred cycles (!!) if it misses in the L1, L2 and has to go to main memory.
I'm wondering how long 'til such viruses use content-anonymizer networks like freenet to download malicious code (20 hardcoded IP addresses is hardly effective)
Sony doesn't sell its Playstations at a loss, it sells them at zero profit (the advantage of developing and manufacturing the chips in-house...). That's quite a difference.
The Xbox is still a colossal loss for Microsoft - but they're pretty much the only ones who can afford it.
Regardless, I've had an uptime of 214 days with Linux on a 2-CPU Pentium 4, with a stock RedHat 2.4.18 kernel. The reason it went down was because the computer had to be moved from one location to another...
Yes, I've noticed instability on the stable kernel - but that happened mostly with my own kernel builds. That is why we have distros - let them heavily test, use their kernels *and* make your purchasing decisions based on their hardware compatibility lists. When you compile your own configs, there's clearly some risk that you're undertaking (compiling kernels isn't for aunt tillie - sorry Bruce)
Furthermore, don't make empty assumptions about what kernel hackers test their work on:). Trust me, RH & Suse *do* test on high-end hardware. Not to mention the gargantuan hardware that IBM ships with Linux as the OS.
I'm pretty sure the problem should be solved by now, but I was just wondering, with so many soldiers having RF equipment on them, how do you "fight" against triangulation ? (why you'd do that is kinda' obvious)
LUFS - userland filesystem. It's a userland "teleportation" of the VFS infrastructures (a kernel module sends all the queries to a userland daemon, which takes care of the protocol, etc).
The advantage of this approach is that adding a new filesystem type implies modifying a user-space daemon, not the kernel. LUFS includes, besides sshfs ftpfs, gnomefs, and gnutellafs and a few others
No mention in the article about the half-life of nuclear waste. It's about a million years!!! While the whole waste does indeed fit into a two-story building, you need a building (container) that can survive about a million years. No structure - geological or man-built can do that.
The only safe way of getting rid of them would be to send them into the sun, but that would take (with today's technology) make more waste than what it would get rid of.
Redhat doesn't do the same thing (i.e. countersue). They could just as well claim that this is unfair competition.
Have Mandrake sue them in the States and France, and they're gonna have enough legal pressure to last them until they cease to exist as a company (which one way or the other will very likely happen, as this process is their last bet of making money)
The reason medical care costs so much is because the principles of free market are applied to it. And I'm not talking about competition - which is great, I'm talking about option. Free market works well in the places where both the buyer and the seller actually have an option whether to complete the transaction or not. When that's not the case, it degenerates into "pay or die", which is clearly an exageration, but not very far from the current state of affairs.
I agree with you that Asia is the current battleground, however bribing is sooo much easier done in poor countries like India or China. The only difference is that the bribing in the US is done in open view (see Republican election funding).
Playing a game in an office has the same effect on geeks as opening a nude calendar. The harmful effects are not on the person playing the game, but on the coworkers.
With just 64K of L2 cache, a PIII or Athlon running at the same frequency will just beat the shit out of it. So this processor is clearly targetted to the embedded market.
No the problem with this market is that x86 compatibility doesn't matter as much as in the desktop market, and... ARM is pretty much the king here. IOW - I won't be buying VIA stocks any time soon.
I agree with you, except for one thing - in the example above a and b are regular ints - they don't have locks associated with it. Your example would never deadlock, as there's a single monitor (the one associated with "this")
Anyway, the common case for locks is that they're aquired immediately - and that's how you measure their overhead.
A smart optimizer would figure out that no other loaded class overrides a given method, and would optimize accordingly, whether or not you've hinted so by declaring it final.
I agree with you, up to a point - in Java the class hierarchy is dynamic, so you can always load a class that screws up the compiler's assumptions. Now the overhead of recompiling everything is too big, so most JVMs are just extremely conservative about it. Towerj supports only limited class loading (IIRC) so it can do it well, but that's not "Java"
Why ? Because it depends so much on the performance optimizations the JVM employs. Let's take them one by one: <br> <LI> Final methods and classes - when you call a final method from the same class you save a lookup in the virtual method table (there is no doubt about what method is going to be called, as it couldn't have been overwritten in a descendent), and furthermore you can inline that method. On a "stupid" JVM (read: from Sun) you won't see any difference, on an optimized one you will.
<LI> Synchronization can become a bottleneck on SMP systems, because it implies cache synchronization (exiting a synchronized block is a memory barrier) - you clearly aren't going to see it on a single processor. But not using synchronization is just as bad (you should use synchronization with <b>all</b> variables that are shared, because you do want memory barriers for correctness)
<LI> Immutable objects - this one clearly depends on the garbage collector that you use. <p> Conclusion: the performance of these tricks depend on two things - your JVM and Amdahl's law (how often are these improvements going to manifest themselves) <p>
Slashdot Mirror
megalo != mega. megalo, according to m-w.com, means "of giant size", "grandiose" (e.g. megalomania).
I'm afraid that if you have a laptop, boot time is quite important. Doing suspend/resume with X running is not reliable. While I certainly agree that fixing this is the long term solution, a quicker boot-up is a reasonable fix in the meanwhile
Furthermore, you don't *need* the commercial version - that's how the Zaurii replacement ROMs were built in the first place. Furthermore, for a new device I'd expect a lot more work to be required in the kernel than in the user interface.
Since Flash is so cheap these days, it would have been better (IMHO) to have the home filesystem on flash and not within RAM, just like recent Zaurii. I don't know a single person who hasn't lost PDA data because of battery ...
The Raven.
The difference is that the mobile phone signal is much, much stronger. Using a mobile phone near a radio will give you an idea (and you'll see why their usage is always prohibited on airliners, as oposed to other electronic devices, which are allowed after takeoff)
The only good thing about such patents is that they expire in 20 years, and you only have 1 year after you publish the idea to apply for a patent. So ancient stuff is fortunately rulled out.
Technology and FPS aside, Nvidia's support for Linux shines in comparison to ATI's offer. I'd really hate it if they follow 3dfx's path.
http://www.thekompany.com/embedded/devices/
It's not going to come from 64 vs. 32 bit as much as from the 8 extra general purpose registers (GPRs). With 8 registers (x86 architecture) you can do very little register allocation, and consequently have to go to memory almost every time you do an operation. +8 registers changes this significantly. The register file is very fast to access and also has a fixed cost, whereas a memory operation can take a couple of hundred cycles (!!) if it misses in the L1, L2 and has to go to main memory.
I'm wondering how long 'til such viruses use content-anonymizer networks like freenet to download malicious code (20 hardcoded IP addresses is hardly effective)
Draw your own conclusion :).
I say they should fire the prime minister and finance minister right away, they have much better uses for the money.
The Xbox is still a colossal loss for Microsoft - but they're pretty much the only ones who can afford it.
Regardless, I've had an uptime of 214 days with Linux on a 2-CPU Pentium 4, with a stock RedHat 2.4.18 kernel. The reason it went down was because the computer had to be moved from one location to another ...
Yes, I've noticed instability on the stable kernel - but that happened mostly with my own kernel builds. That is why we have distros - let them heavily test, use their kernels *and* make your purchasing decisions based on their hardware compatibility lists. When you compile your own configs, there's clearly some risk that you're undertaking (compiling kernels isn't for aunt tillie - sorry Bruce)
Furthermore, don't make empty assumptions about what kernel hackers test their work on :). Trust me, RH & Suse *do* test on high-end hardware. Not to mention the gargantuan hardware that IBM ships with Linux as the OS.
I'm pretty sure the problem should be solved by now, but I was just wondering, with so many soldiers having RF equipment on them, how do you "fight" against triangulation ? (why you'd do that is kinda' obvious)
The advantage of this approach is that adding a new filesystem type implies modifying a user-space daemon, not the kernel. LUFS includes, besides sshfs ftpfs, gnomefs, and gnutellafs and a few others
The only safe way of getting rid of them would be to send them into the sun, but that would take (with today's technology) make more waste than what it would get rid of.
Have Mandrake sue them in the States and France, and they're gonna have enough legal pressure to last them until they cease to exist as a company (which one way or the other will very likely happen, as this process is their last bet of making money)
The reason medical care costs so much is because the principles of free market are applied to it. And I'm not talking about competition - which is great, I'm talking about option. Free market works well in the places where both the buyer and the seller actually have an option whether to complete the transaction or not. When that's not the case, it degenerates into "pay or die", which is clearly an exageration, but not very far from the current state of affairs.
I agree with you that Asia is the current battleground, however bribing is sooo much easier done in poor countries like India or China. The only difference is that the bribing in the US is done in open view (see Republican election funding).
Playing a game in an office has the same effect on geeks as opening a nude calendar. The harmful effects are not on the person playing the game, but on the coworkers.
No the problem with this market is that x86 compatibility doesn't matter as much as in the desktop market, and ... ARM is pretty much the king here. IOW - I won't be buying VIA stocks any time soon.
Anyway, the common case for locks is that they're aquired immediately - and that's how you measure their overhead.
I agree with you, up to a point - in Java the class hierarchy is dynamic, so you can always load a class that screws up the compiler's assumptions. Now the overhead of recompiling everything is too big, so most JVMs are just extremely conservative about it. Towerj supports only limited class loading (IIRC) so it can do it well, but that's not "Java"
Why ? Because it depends so much on the performance optimizations the JVM employs.
Let's take them one by one:
<br>
<LI> Final methods and classes - when you call a final method from the same class you save a lookup in the virtual method table (there is no doubt about what method is going to be called, as it couldn't have been overwritten in a descendent), and furthermore you can inline that method. On a "stupid" JVM (read: from Sun) you won't see any difference, on an optimized one you will.
<LI> Synchronization can become a bottleneck on SMP systems, because it implies cache synchronization (exiting a synchronized block
is a memory barrier) - you clearly aren't going to see it on a single processor. But not using synchronization is just as bad (you should use synchronization with <b>all</b> variables that are shared, because you do want memory barriers for correctness)
<LI> Immutable objects - this one clearly depends on the garbage collector that you use.
<p>
Conclusion: the performance of these tricks depend on two things - your JVM and Amdahl's law (how often are these improvements going to manifest themselves)
<p>