Borrow SCO shares. Borrowing shares is the way of making money when you predict the stock price will go down. You basically get shares, dump them, and after a pre-established period, re-purchase them and give them back to the original owner. If the stock goes down, you make money. If it went up, you'd lose.
From a moral perspective, by borrowing shares now you'd be making money of the people who bet against Linux.
Classpath itself is "already there". Classpath is slowly being merged into libgcj.
OTOH GCJ is far from replacing Sun's java (at least in terms of speed). To compile java properly you have to do some funky runtime optimizations (which sometimes even require un-optimizations!), something that the gcc infrastructure doesn't really allow. That's why you get considerably better running speeds with Sun's or IBM's JITs (although you do get better startup speeds with gcj)
What most linux aficionados don't realize is that vi and emacs are the best anti-linux vaccines. The moment you tell a non-technical person that he or she would have to use from now on the usability nightmares that vi and emacs are, you can't be sure that they not only will they run away from linux, but they'd also tell everybody to do the same.
KDE does ctrl-c/ctrl-v in most of its apps, if jedit is too heavy for you, try kate for a change.
Open source project very rarely have the money to do real usability apps, so I think it'd be a good idea to adopt UI elements from existing commercial designs
Everytime you modify a file on the filesystem, the file allocation table gets modified... And pretty much everybody uses FAT16/FAT32 for CF cards.
jffs2 is much more conscious about write behavior, so I'd strongly recommend it for anything on a flash filesystem.
Anyway, the main reason compact flash is rather slow is simply the fact that few people need high throughput. There are cards these days that sustain a throughput of 15M/s, but they're only meant for high-end cameras. While flash is slower than RAM, it's still considerably faster than mechanical devices, so I'd expect this number to go higher.
For modern processors accessing the register file is considerably faster than accessing the memory (even if the memory access doesn't miss in the L1 cache). With 8 GPRs, the compiler can barely alocate 3 for variables (the rest are needed by the compiler for other stuff). That number increases to 10->11 when going to 16 GPRs.
This means that for small leaf functions you don't need to go to memory at all...
The performance increases of 10-20% is precisely what people got by recompiling with gcc for AMD64. This is, indeed, the reason 64-bit architectures perform better than standard x86/32 bits (Itanium has 128 GPRs for instance...)
For two years, as a matter of fact. I joined for three reasons - 1. I could give back to MDK without paying the
2. Duval's March call (2 years ago) 3. Subscription is the way to go for Linux, IMHO (because of the very rapid movement in the Opensource World)
Once thing I was promised was my voice to be heard. Another one - to get some benefits.
My voice was heard, but only by other members. I asked once - "are we gonna get a dvd iso as well ? (regarding 9.2)". Not a single answer from MDK. When 9.2 was released, Gold members were given an ISO download, but not bronze/silver (I can't really afford a Gold membership, I'm just a student). What I really disliked is that they didn't tell me anything. And nobody can really argue that they didn't notice my message, since the traffic on MDK club is very small.
The benefits - well, the package system is reasonably good. Other than that... it certainly doesn't feel like a subscription service. There are many products (like the x86-64 distro) that are not available for club members at all. For the main distro itself, it felt that I was paying to be a betatester more than a priviledged downloader.
I think that the way to go for MDK is to convert the club
into a true subscription model (not the very ambiguous hafl charity, half business thing that the club currently is). Until then I'll be happily using MDK on my laptops without being a member, but won't be too sorry if I have to switch to Debian.
Legends say that Archimedes wreaked havoc through the Roman invasion fleet trying to conquer Syracuse with giant lenses.
While it's very hard to verify this legend, one thing we know for sure is that Syracuse was conquered via land, and Archimedes ingenuity had an important part to play in defending Syracuse from the sea.
So yeah, this is stuff that matters, but hardly "news"
Reminds me of the episode when Cow and Chicken take part in a kite contest, which ends with Pig effectively surfing lava
Episode III will be just as grotesque, but probably much lamer than Cow and Chicken. I mean, what can you expect from the author that so easily converts archetypes into stereotypes (see Jar Jar Binks)
At the instruction level, these emulators do the "obvious" thing - they interpret instructions, one by one. What they could do instead is trace-based binary rewriting; pretty much like a JIT, you find the hotspots in your program, generate traces for them, then "compile" the traces into native instructions. This is clearly more difficult, but with off-the-shelf compiler technologies like libgcc, shouldn't be that hard.
This is pretty much what Transmeta does, and more recently Intel with x86 on Itanium. The software rewriter actually performs better than the x86 hardware mode of Itanium.
Device emulation is much harder to do fast, but OTOH unless you do 3d games, it's not such a big deal.
The biggest problem with a car, the way I see it, is its gross inefficiency. Regardless of your energy source (electric, chemical, etc.), you're still moving around a ton of steel just to effectively transport one, perhaps two persons (on average).
RSA 2048 is pretty much unbreakable, if they really cared so much about Echelon (which IMHO is a disgusting thing), they'd simply make it standard. The main advantage is that minor changes would be required to the existing infrastructure.
Did you actually limit its buffer with -Xmx ? I guess not, because if you did, thrashing would never occur (eventually you'd get an exception, but that's something else).
Anyway, the "continually growing" thing makes me think of a "soft leak" (e.g. you continually add stuff to a collection). If that's not the case, well, probably a faulty VM or a bad web server (Tomcat, for instance, is rather poorly written)
BTW, Java in 94 was bleeding-edge, it was only with 1.3 that it got truly mainstream.
It's human to err, but diabolic to persevere in your errors.
When I talk with php "developpers" who learnt it by example and without any formal programming background, it's extremely difficult to get past the "but it works very well this way..."
Re:Not quite
on
Hardened PHP
·
· Score: 4, Informative
Java Server Pages - jsp.
Its advantages: faster (java isn't slow, it has a slow startup, which for a server is hardly a big deal), because the code you write is going to be converted in machine code; scales better (PHP still doesn't provide connection pooling; pconnect doesn't count, btw); more secure (no buffer overflow b/c of java, can use security policies to restrict what your pages are doing)
Its disadvantage: well, you have to learn java. You can't just jump into writing jsp pages, as you'd do with php. But I can equally argue that that's an advantage as well, as it increases the quality of code.
You're forgetting the essential
on
Nano Body Building
·
· Score: 2, Interesting
The older the people, the more conservative they become.
Reminds me of Asimov's writings, where the first wave of space colonization eventually fails (among other reasons) because people live hundreds of years.
Not quite
on
Hardened PHP
·
· Score: 4, Interesting
Make no mistakes - in 2001 a security paper claimed that ``it is very hard to write a secure PHP application (in the default configuration of PHP), even if you try''
``A Study In Scarlet - Exploiting Common Vulnerabilities in PHP'' [Clowes 2001]
PHP is probably slightly better these days, but, just like Windoze, simply wasn't designed with security in mind. It's a language grown incrementally, designed to allow you to write websites very quickly. And yes, easy to use means that it attracts people who know very little about programming.
Conclusion: combination of insecure language plus low-quality developpers equals security disaster.
Itanium's instruction set is actually a lot more geared towards scientific computing than server benchmarks. Scientific stuff usually is made of very regular code, that is quite easily schedullable by the compiler. Server stuff is generally memory-bound and very irregular, so the processor usually gets less than one instruction executed per cycle - bundling instructions (static schedulling by the compiler) is completely pointless.
"Big Iron" is a very vague term - server benchmarks behave very differently than scientific computation as far as performance is concerned; if you don't believe me I can easily point you to a couple of research papers analyzing them.
The humongous on-die caches makes the Itanium perform well on servers, and definitely not the instruction-set architecture. So "WAS DESIGNED FOR" is only 50% true.
Binaries - there's no "clean" way of getting them, AFAIC. You need VS.NET and ask M$ for the devel kit in order to compile them (at which time you're bound by their EULA, which disallows redistribution). Well, I definitely wouldn't mind a download link though:)
Slashdot Mirror
From a moral perspective, by borrowing shares now you'd be making money of the people who bet against Linux.
OTOH GCJ is far from replacing Sun's java (at least in terms of speed). To compile java properly you have to do some funky runtime optimizations (which sometimes even require un-optimizations!), something that the gcc infrastructure doesn't really allow. That's why you get considerably better running speeds with Sun's or IBM's JITs (although you do get better startup speeds with gcj)
Sure
I'm just wondering ... how effective are Windoze adds on MS-bashing sites ? IMHO it's more of a problem with the advertising company, not linuxtoday.
You do need a horde of developpers to get drivers, which you either have to pay or entice with a truly open model. Be did neither.
If Machiavelli lived today, his quintesential book would be called "Il Executivo", not "Il Principe"
What most linux aficionados don't realize is that vi and emacs are the best anti-linux vaccines. The moment you tell a non-technical person that he or she would have to use from now on the usability nightmares that vi and emacs are, you can't be sure that they not only will they run away from linux, but they'd also tell everybody to do the same.
KDE does ctrl-c/ctrl-v in most of its apps, if jedit is too heavy for you, try kate for a change.
Open source project very rarely have the money to do real usability apps, so I think it'd be a good idea to adopt UI elements from existing commercial designs
jffs2 is much more conscious about write behavior, so I'd strongly recommend it for anything on a flash filesystem.
Anyway, the main reason compact flash is rather slow is simply the fact that few people need high throughput. There are cards these days that sustain a throughput of 15M/s, but they're only meant for high-end cameras. While flash is slower than RAM, it's still considerably faster than mechanical devices, so I'd expect this number to go higher.
I'd say quite a few /.-ers wouldn't mind fat chicks.
The performance increases of 10-20% is precisely what people got by recompiling with gcc for AMD64. This is, indeed, the reason 64-bit architectures perform better than standard x86/32 bits (Itanium has 128 GPRs for instance ...)
Once thing I was promised was my voice to be heard. Another one - to get some benefits.
My voice was heard, but only by other members. I asked once - "are we gonna get a dvd iso as well ? (regarding 9.2)". Not a single answer from MDK. When 9.2 was released, Gold members were given an ISO download, but not bronze/silver (I can't really afford a Gold membership, I'm just a student). What I really disliked is that they didn't tell me anything. And nobody can really argue that they didn't notice my message, since the traffic on MDK club is very small.
The benefits - well, the package system is reasonably good. Other than that ... it certainly doesn't feel like a subscription service. There are many products (like the x86-64 distro) that are not available for club members at all. For the main distro itself, it felt that I was paying to be a betatester more than a priviledged downloader.
I think that the way to go for MDK is to convert the club into a true subscription model (not the very ambiguous hafl charity, half business thing that the club currently is). Until then I'll be happily using MDK on my laptops without being a member, but won't be too sorry if I have to switch to Debian.
While it's very hard to verify this legend, one thing we know for sure is that Syracuse was conquered via land, and Archimedes ingenuity had an important part to play in defending Syracuse from the sea.
So yeah, this is stuff that matters, but hardly "news"
Episode III will be just as grotesque, but probably much lamer than Cow and Chicken. I mean, what can you expect from the author that so easily converts archetypes into stereotypes (see Jar Jar Binks)
This is pretty much what Transmeta does, and more recently Intel with x86 on Itanium. The software rewriter actually performs better than the x86 hardware mode of Itanium.
Device emulation is much harder to do fast, but OTOH unless you do 3d games, it's not such a big deal.
The biggest problem with a car, the way I see it, is its gross inefficiency. Regardless of your energy source (electric, chemical, etc.), you're still moving around a ton of steel just to effectively transport one, perhaps two persons (on average).
RSA 2048 is pretty much unbreakable, if they really cared so much about Echelon (which IMHO is a disgusting thing), they'd simply make it standard. The main advantage is that minor changes would be required to the existing infrastructure.
orionserver.com
Anyway, the "continually growing" thing makes me think of a "soft leak" (e.g. you continually add stuff to a collection). If that's not the case, well, probably a faulty VM or a bad web server (Tomcat, for instance, is rather poorly written)
BTW, Java in 94 was bleeding-edge, it was only with 1.3 that it got truly mainstream.
It's human to err, but diabolic to persevere in your errors.
When I talk with php "developpers" who learnt it by example and without any formal programming background, it's extremely difficult to get past the "but it works very well this way ..."
Its advantages: faster (java isn't slow, it has a slow startup, which for a server is hardly a big deal), because the code you write is going to be converted in machine code; scales better (PHP still doesn't provide connection pooling; pconnect doesn't count, btw); more secure (no buffer overflow b/c of java, can use security policies to restrict what your pages are doing)
Its disadvantage: well, you have to learn java. You can't just jump into writing jsp pages, as you'd do with php. But I can equally argue that that's an advantage as well, as it increases the quality of code.
Reminds me of Asimov's writings, where the first wave of space colonization eventually fails (among other reasons) because people live hundreds of years.
``A Study In Scarlet - Exploiting Common Vulnerabilities in PHP'' [Clowes 2001]
PHP is probably slightly better these days, but, just like Windoze, simply wasn't designed with security in mind. It's a language grown incrementally, designed to allow you to write websites very quickly. And yes, easy to use means that it attracts people who know very little about programming.
Conclusion: combination of insecure language plus low-quality developpers equals security disaster.
That's how you can make money of a plunging stock. You borrow them now, sell now, and repurchase them later (for the lender) at a lower price.
"Big Iron" is a very vague term - server benchmarks behave very differently than scientific computation as far as performance is concerned; if you don't believe me I can easily point you to a couple of research papers analyzing them.
The humongous on-die caches makes the Itanium perform well on servers, and definitely not the instruction-set architecture. So "WAS DESIGNED FOR" is only 50% true.
And yet, there were times when it was not only acceptable, it was the hot new thing, which much better quality than AM.
Binaries - there's no "clean" way of getting them, AFAIC. You need VS.NET and ask M$ for the devel kit in order to compile them (at which time you're bound by their EULA, which disallows redistribution). Well, I definitely wouldn't mind a download link though :)
Because you can't trademark them. It's that simple.