A while ago (with a previous generation of wind turbine technology, for sure) someone built a particularly large wind turbine on one of the windier islands of Scotland's west coast, hoping to replace (or lessen) expensive shipments of fuel oil. Power production was fine, but the locals were driven to distraction by the noise the thing produced, particularly when the windspeed was high. I believe it produced a very loud "whump" every second or so, loud enough that no-one could sleep. I believe the conclusion to which the developers came was that very large turbines were prone to this problem.
Still, that was a while ago (maybe a decade) so I'd imagine the developers of this new megaturbine will have engineered out the "whump" issue.
If you really are waiting for the disk to spin more threads aren't going to help you
Yes, if you only have one disk. But again, if you only have one disk you really shouldn't have bought a hideously expensive Sun box. On the Sun box you sensibly should have either a storage appliance (NAS) or a SAN. So you can do lots of concurrent disk IO, all over a half-decent protocol that allows this concurrency without synchronously grinding to a halt whenever one disk is taking its time (as you can do interleaved concurrent reads and writes on both NFS and FiberChannel). So with a decently configured storage solution, disk becomes another multi-headed asychronous "waitee". Yes, as before, for lots of applications the threading will have little or no benefit; but as before, for the kinds of thinks people still buy Sun-SPARC hardware, there's _lots_ of cases where this will help, a lot.
That's true, but until nio introduced polled IO, the best behaved java developer either had to choose to have rather a lot of threads or have their program crippled by IO waits. So there's a lot of code out there that does make lots of threads (and it's a handy programming paradigm even now, so it's not going away any time soon).
As the poster above says, it's only an improvement if you've got lots of threads. So an application server is a prime example - it ends up running _lots_ of servlet instances simultaneously, as it's mostly IO bound (waiting for disks to spin, database servers to respond, xml-messaging backoffice thingies to commune with antique cobol boxes, etc.). This kind of application will really benefit - other stuff (e.g graphics, raw-calculation) largely won't - but stuff like Websphere and Tomcat is exactly what folks buy mid/high end Solaris-SPARC boxes for.
As to problems on "non-Windows" environments, you'll find fantastic thread handling on AIX, HP/UX, and Solaris, where tens of thousands of extant threads isn't going to bring the machine to its knees. NT is okay, I don't know about the BSDs. Linux _was_ horrible, but I know a bunch of work has gone into threads recently, both in the library and in 2.6 - I don't know how much better this has made things.
The only really significant change needs to be in the lower levels of Solaris' scheduler, so that it handles the context switches properly. Solaris already does that for existing SPARC architectures with thread level parallelism support. The only difference the OS sees is the caches and the number of available "slots" for running LWPs.
Of course, you'll only see a significant benefit when you've lots of threads in the run-ready state (which mostly happens when you have lots of threads, period). Given java's fondness for threads, and solaris' already outstanding handling of systems with thousands of threads, this seems like a smart optimisation choice.
So, with the necessary Solaris installed, your existing Tomcat running on your existing JVM will see all the benefits.
The paper in question says their watermarks resist "attacks" from regular java bytecode obfuscators, and from decompile-recompile. But neither of these are "attacks" at all - neither class of program was designed to deliberately remove watermarks. It's very similar to the way digital image watermarks can survive some simple photoshop operations like crop, resize, etc. Photoshop isn't a watermark attack tool either - but Ed Felten's team had little difficulty in designing custom programs that could remove watermarks from digital pictures and audio. The paper doesn't include proper programs written to attack their watermarks.
Currently, there seems to be no way to embed a sensible digital watermark that can't be removed from audio, as one can always make little changes to the original that make little difference to the listener, but upon which the watermark depends. I figure the same is true for software - one can always add new variables, reorder parameters, reorder instructions and insert fake ones, unroll loops, inline functions, stuff like that. It's what polymorphic viruses have been doing for years.
So could one use a virus checker to find GPL software fragments in binaries? No. Embed an existing virus in another (itself polymorphic and/or encrypting) shield, and the virus checkers won't find it.
So, this _might_ find code fragements unintentionally or idly included in a proprietary binary. But if a manufacturer wants to deliberately steal software, then they can encrypt it and polymorph it, and it'll take reverse engineering to find it. And the whole point of these watermarks is that they work automatically, without the need for reverse engineering.
The London failure is really quite unlike those in the US and Italy, and undermines the doom-laden tone of this piece. In both the US and Italy a simple failure caused the failure of one subnetwork, which then propagated to many other subnetworks, bringing down a large part of the country in both cases. In the London case, the domino-failure didn't happen. Most of Greater London was unaffected, and there was no problem elsewhere in the UK, or in France. It's probably for this reason that the outage was limited to three or four hours, whereas the US and Italian cases lasted days in places.
This shows that a developed country can, if it's careful, structure its electricity network in a more durable manner.
I did this on myself also, and I found out the following:
- 5 visits to 8-ball's bomb shop in Harwood - 45 visits to various branches of AmmuNation around the city - two purchases of rocket launchers from Phil's Army Surplus
I don't see what the big deal is. What could anyone infer from that?
George W.Bush, president of the A met today with the Chancellor of
Uchland and the President of Ance. Later he will talk on the telephone
with Mr Putin, president of Ssia, and with Mr Blair, Prime minister
of nothing.
MIDP UI's "abstract commands" (for which Wagner is largely responsible) are just about the cleverest part of any UI in current production (in mainstream systems). It's the best evidence yet that a declarative style of UI specification beats tired old procedural programming for >90% of the "real world" activities one is likely to do on a limited UI device (excepting games, naturally).
The challenge of any style guide (whether it's for MIDP, SVG, HTML, or whatever) is trying to get developers to stick to writing content and not interfere with the user agent (the MIDP environment on a specific phone in this case) and its job of actually representing the UI in concrete form.
It's the same challenge UI framework designers have always had, and there's always l33t fanboyz who insist on implementing (generally very badly) their own widgets, just so they can have animated bass-relief shaded transparent buttons. Egomanical "I'll write all the pixels myself" content creators make the web a pain (flash, applets, mad DHTML), but on more varied and less forgiving mobile-device platforms this will simply result in stuff that just doesn't work.
We're already seeing "works only on Nokia 1234 or Ericsson Tfoo platforms" midlets, which are the MIDP equivalent of "works best with IE5" banners (which naturally should be subtitled "I'm an abject fucking moron who doesn't know how to write portable stuff, or doesn't care").
So this isn't just a style-guide. It's a weapon in the eternal struggle between good and stupid.
One would think that, given the kind of applications for which parallel super computers
are used, that it would be (in some cases) efficient to do the computation in arrays
of FPGAs loaded with application-specific designs.
This is kind of a compromise between each node being a slow but adaptable general
purpose CPU (with maximum flexibility) and a super fast (but inflexible) ASIC.
Perhaps the big barrier to this would be making the math and physics geeks write verilog, or perhaps writing a really shit-hot fortran->verilog converter.
So, I figure that either a) smarter people have already done this or b) it's really stupid.
I heartily support the readme.sco idea (frankly its wording is fairly mild).
But GCC shouldn't remove SCO support for reasons of pique or spite. As other posters have said, it won't hurt SCO one bit, but to do so would make GCC, FSF, and the entire free/open software community look petty, and perhaps untrustworthy. GNU software has a long history of running on unsupportive or openly hostile platforms (i.e. windows) and its continuing to do so gives users of those platforms an incremental upgrade-path to freedom. Any action like this, however justified it might feel, would do much more to harm innocent SCO customers and the entire free software community's reputation.
Bluetooth: erasing the descernable difference between people with really nice cellphones and those with advanced delusional schizophrenia.
Is that person mubling behind you on the train really an important businessman, or does he just think he is? Worse, is that CIA agent who just dialled your number real, or is he just one of the voices? With bluetooth(tm) there's essentially no way to know!
Next thing you'll be thinking you're living in some kind of futuristic hi-tech paradise where people communicate with lightning-powered machines. Yeah right - you're really still back at the pigfarm on Jutland and it's still 1282. Get used to it.
It's a rather shallow point but, given that we're talking about the rather shallow world of marketing, it's ontopic. Both "free software" and "open source software" are rather poor and uncommunicative terms.
"free" is a particular failure as a word - one can tell this by the fact that it's so frequently followed by the necessary clarification ("free as in speech" or "free as in beer"). One wouldn't describe the Magna Carta or the US Declaration of Independance as a "free document", so describing software that's "unencumbered" as "free" is stretching the meaning of the word rather far. Worse, the overloading of free, as in "without cost" simply serves to confuse matters for the layman further. Why is he being charged for "free software"? Isn't this "freeware"? "Libre" is better, but still not ideal. I don't really have a better phrase, but I bet if GNU software was called "libertyware" then every republican senator would be insisting the F22 ran it and that e-voting systems were fully libertyware. That's horrible and lowbrow and cheap, and that's often how marketing has to be.
"open source" is a bit better, although there's still _plenty_ of people who have no idea what "source" is. There's also the confusion with Open Standards and Open Systems. Again, I don't have a really good alternative. "community software"?
So, that's my suggestion for our cynical brandname - Community Libertyware. "Meaningless jargon", you might say. Yep, that's the idea.
It's pretty common to enter into some kind of partnership between two companies as a prelude to a merger or buyout. Sun knows it's behind the times in the Linux front, and building that compitency up by itself is a daunting task. Buying SuSE would radically redress the balance for Sun.
Perhaps the question should be - is there any reason Sun _shouldn't_ buy SusE?
The reason it never got into Moz yet is for exactly that reason.
My understanding that there was also a licence incompatibility issue wrt libart. I'd guess that's not an issue for the GDI+ win32 build, but has the libart licence issue been resolved?
Last I heard, maybe they were going to support the static SVG mini-spec or something.
The maturity level of both mozilla svg and some of the others (I'm most familiar with batik) shows that everyone seems to have most of the static features down; it's the dynamic features that (unsurprisingly) have lots of work yet to do. The SVG spec describes a static subset, as you say - they call it "Conforming Static SVG Viewers". The strategy you describe is exactly the smart thing everyone should be doing - getting the static stuff perfect and out there. As a web developer I can cope with two levels of SVG support (static and dynamic) particularly as the feature string is exposed in the DOM.
I'd be surprised if they dropped the policy of not including half baked implementations now.
SVG is a brilliant standard, and will go a long way to replace the web's millions of opaque flash and shockwave animations (and any number of "diagram" gifs) with something standard and accessible. I'm exceptionally frustrated that I can't realistically author mission-critical sites with SVG as a major (or even the entire) component.
I do, however, pray thay SVG isn't included into standard mozilla (or any other browser) until it's reached maturity (which its page indicates it's pretty far from). I spend too much of my time working around the half-assed CSS implementations of older netscape and IE browsers, and I don't want another decade of worrying about which part of the SVG standard was implemented buggily (sp?) by which version of which browser.
I'm all for beta releases, developer's builds, etc., as the team needs as much feedback from as full an SVG authoring community as it can. But as soon as someone starts authoring sites that depend on the weird vagaries of one browser or another's SVG misimplementation, we'll be going down a painfull bug-for-bug compatibility road. Caveat.
Quite, but unlike regular applications of parabolic reflectors, we don't want to receive/emit collimated radiation - we want to use a (very) slightly nonparabolic reflector to bring our signal'o'doom to an approximate focus out there at 40000km. We want low energy density down here where the air is thick, and the highest possible up there at the warm end of the equation. Still (as throwaway's very astute comment points out) it's going to need to be a whopping dish on the ground to get this to work. I doubt my Radio Shack storecard will cover the cost...
Aside: man, this conversation is going to get us all sent to Guantanamo. We can hardly claim that we only intend to zap axis of evil comsats, as the most hi-tech weapon in the cuban arsenal is an asthmatic donkey with a straw hat.
Slashdot Mirror
Hey, steward, what's that thing on the wing?
A while ago (with a previous generation of wind turbine technology, for sure) someone built a particularly large wind turbine on one of the windier islands of Scotland's west coast, hoping to replace (or lessen) expensive shipments of fuel oil. Power production was fine, but the locals were driven to distraction by the noise the thing produced, particularly when the windspeed was high. I believe it produced a very loud "whump" every second or so, loud enough that no-one could sleep. I believe the conclusion to which the developers came was that very large turbines were prone to this problem.
Still, that was a while ago (maybe a decade) so I'd imagine the developers of this new megaturbine will have engineered out the "whump" issue.
I haven't tried SmartFTP (so I can't compare the two) but if you haven't already tried it, take look at filezilla, which is pretty good.
Yes, if you only have one disk. But again, if you only have one disk you really shouldn't have bought a hideously expensive Sun box. On the Sun box you sensibly should have either a storage appliance (NAS) or a SAN. So you can do lots of concurrent disk IO, all over a half-decent protocol that allows this concurrency without synchronously grinding to a halt whenever one disk is taking its time (as you can do interleaved concurrent reads and writes on both NFS and FiberChannel). So with a decently configured storage solution, disk becomes another multi-headed asychronous "waitee". Yes, as before, for lots of applications the threading will have little or no benefit; but as before, for the kinds of thinks people still buy Sun-SPARC hardware, there's _lots_ of cases where this will help, a lot.
That's true, but until nio introduced polled IO, the best behaved java developer either had to choose to have rather a lot of threads or have their program crippled by IO waits. So there's a lot of code out there that does make lots of threads (and it's a handy programming paradigm even now, so it's not going away any time soon). As the poster above says, it's only an improvement if you've got lots of threads. So an application server is a prime example - it ends up running _lots_ of servlet instances simultaneously, as it's mostly IO bound (waiting for disks to spin, database servers to respond, xml-messaging backoffice thingies to commune with antique cobol boxes, etc.). This kind of application will really benefit - other stuff (e.g graphics, raw-calculation) largely won't - but stuff like Websphere and Tomcat is exactly what folks buy mid/high end Solaris-SPARC boxes for. As to problems on "non-Windows" environments, you'll find fantastic thread handling on AIX, HP/UX, and Solaris, where tens of thousands of extant threads isn't going to bring the machine to its knees. NT is okay, I don't know about the BSDs. Linux _was_ horrible, but I know a bunch of work has gone into threads recently, both in the library and in 2.6 - I don't know how much better this has made things.
The only really significant change needs to be in the lower levels of Solaris' scheduler, so that it handles the context switches properly. Solaris already does that for existing SPARC architectures with thread level parallelism support. The only difference the OS sees is the caches and the number of available "slots" for running LWPs.
Of course, you'll only see a significant benefit when you've lots of threads in the run-ready state (which mostly happens when you have lots of threads, period). Given java's fondness for threads, and solaris' already outstanding handling of systems with thousands of threads, this seems like a smart optimisation choice.
So, with the necessary Solaris installed, your existing Tomcat running on your existing JVM will see all the benefits.
A quick google suggests the evil government also has nothing better to do that to protect those stupid "cypherpunks" too: http://www.shmoo.com/mail/cypherpunks/janfeb00/msg 00401.shtml
Further reading:
Information Warfare: Cyberterrorism: Protecting Your Personal Security in the Electronic Age
by Winn L Schwartau, ISBN 1560251328
Novel. I was expecting a "charlie don't websurf", but it's all good.
Currently, there seems to be no way to embed a sensible digital watermark that can't be removed from audio, as one can always make little changes to the original that make little difference to the listener, but upon which the watermark depends. I figure the same is true for software - one can always add new variables, reorder parameters, reorder instructions and insert fake ones, unroll loops, inline functions, stuff like that. It's what polymorphic viruses have been doing for years.
So could one use a virus checker to find GPL software fragments in binaries? No. Embed an existing virus in another (itself polymorphic and/or encrypting) shield, and the virus checkers won't find it.
So, this _might_ find code fragements unintentionally or idly included in a proprietary binary. But if a manufacturer wants to deliberately steal software, then they can encrypt it and polymorph it, and it'll take reverse engineering to find it. And the whole point of these watermarks is that they work automatically, without the need for reverse engineering.
Code cannot enforce law.
This shows that a developed country can, if it's careful, structure its electricity network in a more durable manner.
I did this on myself also, and I found out the following:
- 5 visits to 8-ball's bomb shop in Harwood
- 45 visits to various branches of AmmuNation around the city
- two purchases of rocket launchers from Phil's Army Surplus
I don't see what the big deal is. What could anyone infer from that?
George W.Bush, president of the A met today with the Chancellor of Uchland and the President of Ance. Later he will talk on the telephone with Mr Putin, president of Ssia, and with Mr Blair, Prime minister of nothing.
But then, even if life were a Tom Clancy novel it _still_ wouldn't be written by Tom Clancy.
The challenge of any style guide (whether it's for MIDP, SVG, HTML, or whatever) is trying to get developers to stick to writing content and not interfere with the user agent (the MIDP environment on a specific phone in this case) and its job of actually representing the UI in concrete form.
It's the same challenge UI framework designers have always had, and there's always l33t fanboyz who insist on implementing (generally very badly) their own widgets, just so they can have animated bass-relief shaded transparent buttons. Egomanical "I'll write all the pixels myself" content creators make the web a pain (flash, applets, mad DHTML), but on more varied and less forgiving mobile-device platforms this will simply result in stuff that just doesn't work.
We're already seeing "works only on Nokia 1234 or Ericsson Tfoo platforms" midlets, which are the MIDP equivalent of "works best with IE5" banners (which naturally should be subtitled "I'm an abject fucking moron who doesn't know how to write portable stuff, or doesn't care").
So this isn't just a style-guide. It's a weapon in the eternal struggle between good and stupid.
This is kind of a compromise between each node being a slow but adaptable general purpose CPU (with maximum flexibility) and a super fast (but inflexible) ASIC.
Perhaps the big barrier to this would be making the math and physics geeks write verilog, or perhaps writing a really shit-hot fortran->verilog converter.
So, I figure that either a) smarter people have already done this or b) it's really stupid.
(note that, in this case at least, I'm not really talking about reconfigurable computing)
But GCC shouldn't remove SCO support for reasons of pique or spite. As other posters have said, it won't hurt SCO one bit, but to do so would make GCC, FSF, and the entire free/open software community look petty, and perhaps untrustworthy. GNU software has a long history of running on unsupportive or openly hostile platforms (i.e. windows) and its continuing to do so gives users of those platforms an incremental upgrade-path to freedom. Any action like this, however justified it might feel, would do much more to harm innocent SCO customers and the entire free software community's reputation.
Perhaps what they taught you at Hollywood Upstairs Medical School, but here in the real real world, schizophrenia causes (amongst other equally nasty things) hallucinations (seeing, hearing, or feeling things that are not real such as hearing voices telling them to do something)
Bluetooth: erasing the descernable difference between people with really nice cellphones and those with advanced delusional schizophrenia.
Is that person mubling behind you on the train really an important businessman, or does he just think he is? Worse, is that CIA agent who just dialled your number real, or is he just one of the voices? With bluetooth(tm) there's essentially no way to know!
Next thing you'll be thinking you're living in some kind of futuristic hi-tech paradise where people communicate with lightning-powered machines. Yeah right - you're really still back at the pigfarm on Jutland and it's still 1282. Get used to it.
"free" is a particular failure as a word - one can tell this by the fact that it's so frequently followed by the necessary clarification ("free as in speech" or "free as in beer"). One wouldn't describe the Magna Carta or the US Declaration of Independance as a "free document", so describing software that's "unencumbered" as "free" is stretching the meaning of the word rather far. Worse, the overloading of free, as in "without cost" simply serves to confuse matters for the layman further. Why is he being charged for "free software"? Isn't this "freeware"? "Libre" is better, but still not ideal. I don't really have a better phrase, but I bet if GNU software was called "libertyware" then every republican senator would be insisting the F22 ran it and that e-voting systems were fully libertyware. That's horrible and lowbrow and cheap, and that's often how marketing has to be.
"open source" is a bit better, although there's still _plenty_ of people who have no idea what "source" is. There's also the confusion with Open Standards and Open Systems. Again, I don't have a really good alternative. "community software"?
So, that's my suggestion for our cynical brandname - Community Libertyware. "Meaningless jargon", you might say. Yep, that's the idea.
Perhaps the question should be - is there any reason Sun _shouldn't_ buy SusE?
My understanding that there was also a licence incompatibility issue wrt libart. I'd guess that's not an issue for the GDI+ win32 build, but has the libart licence issue been resolved?
Last I heard, maybe they were going to support the static SVG mini-spec or something.
The maturity level of both mozilla svg and some of the others (I'm most familiar with batik) shows that everyone seems to have most of the static features down; it's the dynamic features that (unsurprisingly) have lots of work yet to do. The SVG spec describes a static subset, as you say - they call it "Conforming Static SVG Viewers". The strategy you describe is exactly the smart thing everyone should be doing - getting the static stuff perfect and out there. As a web developer I can cope with two levels of SVG support (static and dynamic) particularly as the feature string is exposed in the DOM.
I'd be surprised if they dropped the policy of not including half baked implementations now.
I wish IE had the same policy.
I do, however, pray thay SVG isn't included into standard mozilla (or any other browser) until it's reached maturity (which its page indicates it's pretty far from). I spend too much of my time working around the half-assed CSS implementations of older netscape and IE browsers, and I don't want another decade of worrying about which part of the SVG standard was implemented buggily (sp?) by which version of which browser.
I'm all for beta releases, developer's builds, etc., as the team needs as much feedback from as full an SVG authoring community as it can. But as soon as someone starts authoring sites that depend on the weird vagaries of one browser or another's SVG misimplementation, we'll be going down a painfull bug-for-bug compatibility road. Caveat.
Quite, but unlike regular applications of parabolic reflectors, we don't want to receive/emit collimated radiation - we want to use a (very) slightly nonparabolic reflector to bring our signal'o'doom to an approximate focus out there at 40000km. We want low energy density down here where the air is thick, and the highest possible up there at the warm end of the equation. Still (as throwaway's very astute comment points out) it's going to need to be a whopping dish on the ground to get this to work. I doubt my Radio Shack storecard will cover the cost...
Aside: man, this conversation is going to get us all sent to Guantanamo. We can hardly claim that we only intend to zap axis of evil comsats, as the most hi-tech weapon in the cuban arsenal is an asthmatic donkey with a straw hat.