Interesting, I have to confess that the only places I ever saw S-100 systems was in industrial applications, and one hardcore computer hobbiest (who got the machine from work, where it was decomissioned from an indistrial application).
"Just like McMoore and MoveOn.org compare Bush to Hitler"
This is a stupid, baseless claim, but it gets repeated so often by partisan mudslingers that I can't let it pass. MoveOn.org held a contest, to which hundreds of people submitted anti-Bush ads. One person submitted an ad comparing Bush to the Nazi's. All submissions were automatically made visible on MoveOn.org's web site so that people could vote on them, and the voting would determine the winner. The "Nazi" ad was pulled from the web site as soon as people complained about it.
And, if you actually watched the ad, rather than reading RNC press released, you'll see that it didn't claim that Bush was a Nazi, or did everything that the Nazi's did. It claimed that Bush used some of the same tactics that the Nazi's used (e.g. "the Big Lie" tactic for getting people to believe useful things that aren't true through repetition, and Goering's famous quote about how easy it is to maneuver a country into supporting a war by attacking your opponents' patriotism). So while it's usually a bad sign when Nazis come into a conversation (people's brains tend to shut off), it's hard to argue that Bush's team didn't use those tactics to promote the invasion of Iraq.
The Apple ][ was an interesting mix of open and closed. Apple certainly kept the ownership of the platform closed (they tried to block the Apple ][ manufacturers, etc.) but at the same time they made their machine extremely open and hacker friendly. I loved the fact that my Apple ][ came with commented ROM listings printed in the manuals, and it was cheap and easy to make cards for the Apple ][.
The S-100 bus, while an open industry standard, really, really sucked to deal with. You had to put more chips on a card to plug it into S-100 than the entire floppy drive controller card for the Apple ][ (admittedly a particularly elegant card). And, on the more pragmatic side, S-100 machines were immense and expensive, while the Apple ][ was (relatively) small and cheap.
I don't recall Apple being "widely derided" for being proprietary hardware, because almost everything everyone used back then was proprietary. The only "open standard" hardware was S-100, which was wildly unsuccessful except in a few industrial niches where "standards" are more important than not sucking (IMO, of course), and the microcomputer market was completely dominated by proprietary hardware (Apple, Commodore, Radio Shack, etc.). IMO, it was simply too early for the industry to evolve hardware standards, because nobody knew what worked and what didn't, so you needed competing technologies to duke it out for a few years.
The irony is that the Apple ][ was successful largely because it was a completely open hardware platform, so it was adapted to hundreds of applications that nobody every expected. Heck, people _still_ use Apple ]['s for industrial control applications.
Apple's iTunes Music Store sells about 70-80% of the music sold online. The number is approximate, because not all sales by all retailers are reported by SoundScan. Specifically, SoundScan only reports digital single sales, and not digital album sales, so iTMS' sales may be underreported by 40% or so (since Apple claims that about 40% of their sales are album sales). But whatever you believe the precise number is, iTMS is dominating in the digital music sales business right now.
"Okay, so how does XML compare to HTML? Remember that HTML does not require closing tags, nor does it require tags be closed in the same order they're opened, nor does it require combo end/begin tags to be explicitly noted.... Are you claiming this is somehow easier for the browser to parse than XHTML?
Or are you proposing that all web servers be replaced with databases, with their horrifically insecure client/server interfaces exposed to the world?"
I'm a little confused by this post, but I'll try to respond.
XML isn't a presentation layer technology -- you don't send (generic) XML to browsers unless you're a sadist. But you can send XHTML, which is a re-spin of HTML that's more strict, which I agree is a distinct improvement.
The model that I was saying was broken was using XML for authoring the web site. Think "interwoven" for example. That model involves people authoring XML documents for all content, with the web site doing XSLT transforms to generate the presentation layer of the web site from the XML. This in intellectually an interesting approach, but ends up creating a huge number of complexities and performance problems when compared to the "traditional" method of generating complex web sites, which is to have authors pump information into a database, which is used to dynamically populate web pages (think PHP, JSP, ASP). In either case, what the browser receives is some flavor of HTML; the question is how that HTML is generated.
This doesn't have anything to do with client/server interfaces.
Yeah, making the transforms a pre-process addresses the performance issues with doing real-time transforms. But I'll point out that many vendors sell real-time transforms as a "feature" of their XML-based app servers, claiming that you can support arbitrary new devices by writing XSLT's to transform your site into WML, SHTML, etc., as needed. This is admittedly true, if you don't need your site to run quickly, or have dynamic content. But if your site is truly dynamic (i.e. it has personalized components on web pages) you can't pre-generate the pages. (OK, I'm simplifying...), so it still only works well for relatively static sites. For example, you could author doc's in docbook, then transform to HTML, XHTML, PDF, WML, etc., flavors of your site, but you'd end up with a bunch of copies of a static site. If your site is interactive (think games, or TV listings, etc.) this approach breaks.
To be clear, I'm saying that using XML as a document format in web site production is insanely inefficient. That is, people author XML documents that are then transformed into a presentation format (e.g. HTML) for delivery. XML authoring tools mainly suck, it's hard to enforce business rules on the data, and the transforms are painfully slow.
I'm not complaining about XHTML at all -- XHTML is a great presentation language, specifically because it's less tolerant of sloppy coding than HTML, so it weeds out broken web sites. It also makes it easy to build lightweight "web services" by parsing the XHTML (assuming it's nicely tagged), which comes in handy from time to time.
But the data behind those web sites should be in a database, not XML.:-)
I'll go out on a limb and say that using XML as the document format for web site production is a terrible idea. XML is a great data exchange language between systems, but it's insanely inefficient for use within a single system. All of XML's positive attributes (self documenting, robust, extensible, supports encodings, validation, use XSLT to do transforms between arbitrary XML representations of data, etc.) are all important between loosely coupled systems. But those issues don't occur within a single system, and the overhead of using XML is immense. It's orders of magnitude faster to query a datbase directly than to parse XML, transform, etc.
Actually, Squeak has had fantastic support for pen-based computing for many years now. It can run over any OS, or even over bare hardware (Smalltalk only relies on a small set of primitives, which can and has been implemented in a few days to bare hardware.) Squeak offers not only pen-based control and text recognition, but also a very rich visual programming model (Morphic). There are an amazing array of app's at http://www.squeakland.org/ to play with. Since Squeak is extremely visual, interactive, and open to hacking (in the positive sense that you can inspect and tweak anything) it's very popular in educational settings. It is, of course, open source.
So yes, it'd be a bit geeky trying to do "real work" in Squeak, it has all of the capabilities you're looking for (Morphic is far more powerful than Windows' imaging model, so you can make presentations that go *far* beyond PowerPoint, Squeak has decent handwriting recognition, etc.).
Yeah, I remember dealing with static linking of shared libaries, and it was a mess. Luckily, even if there's some (extremely unlikely) problem that could force us to move from ELF, there are plenty of dynamic linkers out, and we could use some other binary format comparable in functionality to ELF. I don't think that SCO could claim to have the patent on the _concept_ of dynamic linking, since it was invented long before UNIX. (Or is SCO going to try to claim ownership of Multics because it rhymes with Unix?)
Anyway, if we can't use ELF, we would have to move to another binary format, which means that we would have to pick one new binary format, then recompile and relink of everything. That's a hassle, but it's not fatal.
Doesn't this just mean that each vendor would have to do a clean re-build of their complete Linux distribution? It hardly seems like a big deal, other than the hassle of having to keep the versions straight.
The ICE syndication protocol has solved this. See http://www.icestandard.org.
The short version is that ICE is far more bandwidth efficient than RSS because: - the syndicator and subscriber can negotiate whether to push or pull the content. So if the network allows for true push, the syndicator can push the updates, which is most efficient. This eliminates all of the "check every hour" that crushes RSS syndicators. And while many home users are behind NAT, web sites aren't, and web sites generate tons of syndication traffic that could be handled way more efficiently by ICE. Push means that there are many fewer updates transmitted, and that the updates that are sent are more timely. - ICE supports incremental updates, so the syndicator can send only the new or changed information. This means that the updates that are transmitted are far more efficient. For example, rather than responding to 99% of updates with "here are the same ten stories I sent you last time" you can reply with a tiny "no new stories" message. - ICE also has a scheduling mechanism, so you can tell a subscriber exactly how often you update (e.g. hourly, 9-5, Monday-Friday). This means that even for polling, you're not wasting resources being polled all night. This saves tons of bandwidth for people doing pull updates.
"There are plenty of developers out there who don't work for Microsoft but develop only on Windows platform. Many of them prefer only developing their products to one unified platform -- Windows."
There are two separate issues here:
1) Being able to take advantage of Windows-specific functionality. This is a good thing.
2) Being able to write portable app's. This is also a good thing.
Keep in mind that that these are two separate issues. MS could easily have provided all of their Windows-specific enhancements without breaking the Java API's, giving developers the ability to choose their target platform.
What MS did that wasn't in the interests of either developers or end users was to try to eliminate the option of making portable Java app's, by breaking the Java API's.
"Microsoft's Java support was pretty damn good. It just wan't what Sun wanted."
Well, it wasn't what _anyone_ other than Microsoft wanted. That is, by default with with no warnings, it was very easy for your Java would become Windows-dependent, undermining the fundamental value of Java.
Microsoft could have done all of the innovative things (e.g. calling OS-specific COM objects and other routines easily, nice fast JVM) that they did with their JVM and runtime _without_ violating their Java license, simply by placing their OS-specific enhancements outside of the java.* class heirarchy, by warning developers when they were generating non-portable code, and by supporting all of Java properly. But MS decided that it was more important to try to tie Java developers to Windows than it was to honor the Java license (or, of course, to provide what Java developers wanted).
You mean, like using a public source code control system? There are zillions of projects that use CVS repositories for allowing many people to contribute to the project freely, but there's usually a bit of a process to getting permission to check code in. You do know about the Mozilla project's tools, right? You check code in, and they automatically build the code on all platforms, and run unit tests, and publish the status of the builds on a web page. It's really slick. One of the more subtle bits is that they make broken builds quite obvious (big, red boxes) clearly labeled with the name of whoever did the checkin that broke the build, which produces a strong social pressure to test before checking in, or to fix breakage to get your name off.
Personally, I don't think you'd want to make source code _completely_ publicly writable, because it's more important to keep source code consistent (style, architecture) than text, and the 'submit a patch the maintainer' process does that nicely. But it often takes no more than a simple email exchange to get checkin rights to smaller projects.
"E-voting is insecure and cannot be made secure unless the terminal (computer screen and keyboard) are secure... PC's do not qualify at all. Any wide-spread worm could targed E-voting for instance"
I agree that the physical system needs to be secure, but I disagree that PC's can't be secured. For example, the OVC's solution is that the PC's should be booted from a certified CD-ROM, so all of the software would come from the CD, not from the hard drive, which would only be used for temporary data storage. Also, the PC should certainly not be networked, and removable media ports secured, so there's no easy way for a virus or worm to propagate into the PC.
These steps limit attacks to individuals modifying individual machines, which would break security seals, and otherwise would be detected by poll workers or detective work if attempted on a large enough scale to be effective in altering an election's results. Since a typical polling station records 70 votes in a day, it would take 143 people coordinating to modify enough voting stations to potentially affect 10,000 votes.
And of course, since in the OVC's system the physical ballots are the actual votes, not any digital records, and those ballots are visually inspected by voters before they are cast, compromising the voting stations wouldn't affect the results of the election. This is because even a small percentage of voters checking their ballots would detect any cases of stations mis-printing ballots. And any station that consistently mis-printed ballots (easy to verify) would be removed from service. Statistics is a wonderful thing. So any hacked voting station would only be able to modify a very small number of ballots and not be detected, which means that the number of confederates, and thus the chances of one getting caught, skyrockets. For example, if each hacked polling station only shifted 10% of its printed ballots, that would almost certainly be detected by voters, and on top of that would requite 1,428 confederates to coordinate to install the modified software without any of them getting caught. This is why paper ballots are such a great idea.
"And you need to identify yourself first, so you need an electronic ID or suchlike first"
Actually, due to the requirement that voting be universal, it's illegal to require voters to have any particular form of ID. For example, you can't require a driver's license, because non-drivers can vote. So about all they can check is that your name is on the voter roll, so that you only vote once. Yes, this means that you can go to many polling stations and vote multiple times, but the courts have been very consistent that it's more important to allow everyone to vote than to block fake voters. (of course, poll workers may recognize anyone who tries to vote multiple times in the same location, etc.). Beyond that, it's very important that votes be anonymous so that there's no way to determine how someone voted, because that protects voters from intimidation. So you can't record the voter's ID, or even the timestamp of the vote (since someone could record the times that people enter and leave polling stations, and thus derive your votes). This is why paper ballots are shuffled before they're counted.
"someone should create a good Internet voting mechanism, and keep it anonymous yet feasible"
Someone's creating a good eVoting mechanism, the Open Voting Consortium. Go to http://www.openvotingconsortium.org and help out!
I'll also point out that internet voting is fundamentally insecure, but any vulnerability can be exploited infinitely. When voting takes place in polling stations (i.e. offline and under observation), the poll workers can limit the damage of any vulnerability, because they can see who comes in, control who goes into voting stations, for how long, and can stop anyone doing anything too obvious (e.g. unscrewing the voting stations and modifying their internals, for example). Also, internet voting makes any a reliable audit impossible, because there's no voter verified physical record of a vote.
Just to address one misleading claim: "voter-verified paper record would force voters with disabilities to go back to using ballots that provide neither privacy nor independence, thereby subverting a hallmark of the HAVA legislation." This is not true of any well designed Voter Verified Paper Ballot system. There are several commercial voting systems from smaller companies that produce printed ballots without losing voter privacy or independence. And of course the Open Voting Consortium has implemented an open source eVoting system that allows for voters, including those with with disabilities, to use touchscreens or keyboard to enter their votes (thus eliminating invalid ballots, providing for spoken, multi-lingual prompts, etc.). The system prints paper ballots that the voter can verify, both by visual inspection and by running the ballot through a stand-alone verification station (i.e. that can read the ballot back for the voter to listen to). The paper ballot is the vote, which is counted using scanners, then stored for auditing and/or recounting.
"From the NYT article: 'Before saving a digital song to the hard drive, software can shrink it in size by 50 percent or so just by using a shorthand notation that takes up a little less space for any repetitive patterns in the 0's and 1's.' The author of this article shows no understanding of signal processing or how music data is compressed, so his conclusions are silly. Comparing lossy music compression to 8-track tapes is silly."
Actually, that's a pretty good non-technical explanation for lossless compression.
And the comparison to 8-track makes sense -- it's a lower quality format that was sold as a more portable but lower quality alternative to the LP, analogous to lossy compression is sold as a more portable but lower quality alternative to CD's.
"saving signal data (like photos or music) is always a lossy process, because there no exact digital representation of them"
Of course, going from analog to digital will always (in theory) lose some analog data. But that's sampling, and has nothing to do with compression. You might as well argue that nobody will listen to CD's because of the lost harmonics. Yes, you'd be technically right about the sampling artifacts, but in practice you'd be completely wrong, because CD's sound just fine.
"You decide to save a certain amount of data, let's say, 3 megabytes (or 30 megabytes) for 3 minutes of music, and then you decide what to put in those megabytes. You will always be able to get more/better data into the same space if you use signal processing compressors than if you just use uncompressed samples saved at some sampling rate and width per sample.... If you're saving recorded music, you are always losing data."
This makes no sense. If you've got a digital master, you can't put more/better data into the same space, because you don't have any better data. You can compress the master about 2:1 using lossless compression, because it turns out that there are more efficient ways to encode a pattern (based on repetition, etc.) that are mathematically identical, so you save space without losing any data at all. So I don't know what the 'always losing data' is supposed to me.
You are right, though, that in lossy compression schemes, the CODEC's try to optimize the use of the available bits to minimize the perceived loss of quality.
You should listen to low bit rate AAC+ some time. It's f-ing amazing what people can get out of a 32 Kbps bitstream.
"Unbelievably, any person with a PC and an Internet connection can now logon to the NSA's website and print out the blueprint for NSA s Security Enhanced Linux software."
They say that like it's a bad thing. I suppose it's so obvious it hardly bears stating, excpt that obvious a few people missed it, but in practice a system that is open to inspection is more trustworthy than one that's "secret" because it's better tested. This is one reason that BSD is so much more secure than Windows, Apache is so much more secure than IIS, etc.
"I blieve the 25 Tflop figure is a typo. I've read 15Tflop elsewhere... they're also using plain gigabit ethernet for interconnects, not Infiniband, supposedly because the applications they plan to run don't require a lot of I/O"
Now _this_ makes sense. I can easily believe that a different app could have very different performance characteristics, which could explain a 2x performance difference. That won't affect the Top 500 list too much, though, since it's based on standard benchmarks.
In any case, it's nice to see another Mac supercomputer. It's kinda cool watching the open source world win (since an Xserve is basically an open source machine as far as supercomputing nodes go -- nobody cares about the GUI on a compute node) that's competitive based on raw performance. Go PPC!
"Had you read the article you would have known that thr Army machine is connected using standard gigabit ehternet whereas the Big Mac used Infiniband."
GigE is about 10x slower (for this type of networking, see http://www.infinicon.com/pdf/LSTCUG-2003-Final.pdf ) than Infiniband. That is, unless there's some sort of magic router involved, I don't see how GigE would make CPU's faster.
Perhaps they're measuring different applications, and the Army machine doesn't need much communications? Kinda an odd way to benchmark...
This sounds like a killer system, but I don't follow the performance numbers.
The 1655 CPU cluster is expected to deliver 25 Tflops, while the Virginia Tech machine, with 1,100 CPU's (if I remember properly) is rated at 10 Tflops. What else is different? Are they using a different interconnect? Clever programmers to get closer to peak? Or is it something silly like a journalist switching between peak and measured performance, or between computers and CPU's (assuming dual G5 Xserves)? Or is the G5 Xserve really _that_ much faster than the G5 desktop measures VA Tech was benchmarked with? I _like_ that idea...
Slashdot Mirror
Interesting, I have to confess that the only places I ever saw S-100 systems was in industrial applications, and one hardcore computer hobbiest (who got the machine from work, where it was decomissioned from an indistrial application).
"Just like McMoore and MoveOn.org compare Bush to Hitler"
This is a stupid, baseless claim, but it gets repeated so often by partisan mudslingers that I can't let it pass. MoveOn.org held a contest, to which hundreds of people submitted anti-Bush ads. One person submitted an ad comparing Bush to the Nazi's. All submissions were automatically made visible on MoveOn.org's web site so that people could vote on them, and the voting would determine the winner. The "Nazi" ad was pulled from the web site as soon as people complained about it.
And, if you actually watched the ad, rather than reading RNC press released, you'll see that it didn't claim that Bush was a Nazi, or did everything that the Nazi's did. It claimed that Bush used some of the same tactics that the Nazi's used (e.g. "the Big Lie" tactic for getting people to believe useful things that aren't true through repetition, and Goering's famous quote about how easy it is to maneuver a country into supporting a war by attacking your opponents' patriotism). So while it's usually a bad sign when Nazis come into a conversation (people's brains tend to shut off), it's hard to argue that Bush's team didn't use those tactics to promote the invasion of Iraq.
The Apple ][ was an interesting mix of open and closed. Apple certainly kept the ownership of the platform closed (they tried to block the Apple ][ manufacturers, etc.) but at the same time they made their machine extremely open and hacker friendly. I loved the fact that my Apple ][ came with commented ROM listings printed in the manuals, and it was cheap and easy to make cards for the Apple ][.
The S-100 bus, while an open industry standard, really, really sucked to deal with. You had to put more chips on a card to plug it into S-100 than the entire floppy drive controller card for the Apple ][ (admittedly a particularly elegant card). And, on the more pragmatic side, S-100 machines were immense and expensive, while the Apple ][ was (relatively) small and cheap.
I don't recall Apple being "widely derided" for being proprietary hardware, because almost everything everyone used back then was proprietary. The only "open standard" hardware was S-100, which was wildly unsuccessful except in a few industrial niches where "standards" are more important than not sucking (IMO, of course), and the microcomputer market was completely dominated by proprietary hardware (Apple, Commodore, Radio Shack, etc.). IMO, it was simply too early for the industry to evolve hardware standards, because nobody knew what worked and what didn't, so you needed competing technologies to duke it out for a few years.
The irony is that the Apple ][ was successful largely because it was a completely open hardware platform, so it was adapted to hundreds of applications that nobody every expected. Heck, people _still_ use Apple ]['s for industrial control applications.
There are two numbers getting crossed here.
Apple's iTunes Music Store sells about 70-80% of the music sold online. The number is approximate, because not all sales by all retailers are reported by SoundScan. Specifically, SoundScan only reports digital single sales, and not digital album sales, so iTMS' sales may be underreported by 40% or so (since Apple claims that about 40% of their sales are album sales). But whatever you believe the precise number is, iTMS is dominating in the digital music sales business right now.
Apple's iPod is about 60% of the hard drive-based MP3 player market, and 39% of the total MP3 player market. This makes the iPod the clear leader (the second place vendor has 15%, then it drops from there), but not as completely dominant as they are in music sales.
Of course, this is a dyanic business, so anything could change...
"Okay, so how does XML compare to HTML? Remember that HTML does not require closing tags, nor does it require tags be closed in the same order they're opened, nor does it require combo end/begin tags to be explicitly noted.... Are you claiming this is somehow easier for the browser to parse than XHTML?
Or are you proposing that all web servers be replaced with databases, with their horrifically insecure client/server interfaces exposed to the world?"
I'm a little confused by this post, but I'll try to respond.
XML isn't a presentation layer technology -- you don't send (generic) XML to browsers unless you're a sadist. But you can send XHTML, which is a re-spin of HTML that's more strict, which I agree is a distinct improvement.
The model that I was saying was broken was using XML for authoring the web site. Think "interwoven" for example. That model involves people authoring XML documents for all content, with the web site doing XSLT transforms to generate the presentation layer of the web site from the XML. This in intellectually an interesting approach, but ends up creating a huge number of complexities and performance problems when compared to the "traditional" method of generating complex web sites, which is to have authors pump information into a database, which is used to dynamically populate web pages (think PHP, JSP, ASP). In either case, what the browser receives is some flavor of HTML; the question is how that HTML is generated.
This doesn't have anything to do with client/server interfaces.
Yeah, making the transforms a pre-process addresses the performance issues with doing real-time transforms. But I'll point out that many vendors sell real-time transforms as a "feature" of their XML-based app servers, claiming that you can support arbitrary new devices by writing XSLT's to transform your site into WML, SHTML, etc., as needed. This is admittedly true, if you don't need your site to run quickly, or have dynamic content. But if your site is truly dynamic (i.e. it has personalized components on web pages) you can't pre-generate the pages. (OK, I'm simplifying...), so it still only works well for relatively static sites. For example, you could author doc's in docbook, then transform to HTML, XHTML, PDF, WML, etc., flavors of your site, but you'd end up with a bunch of copies of a static site. If your site is interactive (think games, or TV listings, etc.) this approach breaks.
To be clear, I'm saying that using XML as a document format in web site production is insanely inefficient. That is, people author XML documents that are then transformed into a presentation format (e.g. HTML) for delivery. XML authoring tools mainly suck, it's hard to enforce business rules on the data, and the transforms are painfully slow.
:-)
I'm not complaining about XHTML at all -- XHTML is a great presentation language, specifically because it's less tolerant of sloppy coding than HTML, so it weeds out broken web sites. It also makes it easy to build lightweight "web services" by parsing the XHTML (assuming it's nicely tagged), which comes in handy from time to time.
But the data behind those web sites should be in a database, not XML.
Nope, you're right.
I'll go out on a limb and say that using XML as the document format for web site production is a terrible idea. XML is a great data exchange language between systems, but it's insanely inefficient for use within a single system. All of XML's positive attributes (self documenting, robust, extensible, supports encodings, validation, use XSLT to do transforms between arbitrary XML representations of data, etc.) are all important between loosely coupled systems. But those issues don't occur within a single system, and the overhead of using XML is immense. It's orders of magnitude faster to query a datbase directly than to parse XML, transform, etc.
Actually, Squeak has had fantastic support for pen-based computing for many years now. It can run over any OS, or even over bare hardware (Smalltalk only relies on a small set of primitives, which can and has been implemented in a few days to bare hardware.) Squeak offers not only pen-based control and text recognition, but also a very rich visual programming model (Morphic). There are an amazing array of app's at http://www.squeakland.org/ to play with. Since Squeak is extremely visual, interactive, and open to hacking (in the positive sense that you can inspect and tweak anything) it's very popular in educational settings. It is, of course, open source.
So yes, it'd be a bit geeky trying to do "real work" in Squeak, it has all of the capabilities you're looking for (Morphic is far more powerful than Windows' imaging model, so you can make presentations that go *far* beyond PowerPoint, Squeak has decent handwriting recognition, etc.).
Yeah, I remember dealing with static linking of shared libaries, and it was a mess. Luckily, even if there's some (extremely unlikely) problem that could force us to move from ELF, there are plenty of dynamic linkers out, and we could use some other binary format comparable in functionality to ELF. I don't think that SCO could claim to have the patent on the _concept_ of dynamic linking, since it was invented long before UNIX. (Or is SCO going to try to claim ownership of Multics because it rhymes with Unix?)
Anyway, if we can't use ELF, we would have to move to another binary format, which means that we would have to pick one new binary format, then recompile and relink of everything. That's a hassle, but it's not fatal.
Doesn't this just mean that each vendor would have to do a clean re-build of their complete Linux distribution? It hardly seems like a big deal, other than the hassle of having to keep the versions straight.
The ICE syndication protocol has solved this. See http://www.icestandard.org.
The short version is that ICE is far more bandwidth efficient than RSS because:
- the syndicator and subscriber can negotiate whether to push or pull the content. So if the network allows for true push, the syndicator can push the updates, which is most efficient. This eliminates all of the "check every hour" that crushes RSS syndicators. And while many home users are behind NAT, web sites aren't, and web sites generate tons of syndication traffic that could be handled way more efficiently by ICE. Push means that there are many fewer updates transmitted, and that the updates that are sent are more timely.
- ICE supports incremental updates, so the syndicator can send only the new or changed information. This means that the updates that are transmitted are far more efficient. For example, rather than responding to 99% of updates with "here are the same ten stories I sent you last time" you can reply with a tiny "no new stories" message.
- ICE also has a scheduling mechanism, so you can tell a subscriber exactly how often you update (e.g. hourly, 9-5, Monday-Friday). This means that even for polling, you're not wasting resources being polled all night. This saves tons of bandwidth for people doing pull updates.
"There are plenty of developers out there who don't work for Microsoft but develop only on Windows platform. Many of them prefer only developing their products to one unified platform -- Windows."
There are two separate issues here:
1) Being able to take advantage of Windows-specific functionality. This is a good thing.
2) Being able to write portable app's. This is also a good thing.
Keep in mind that that these are two separate issues. MS could easily have provided all of their Windows-specific enhancements without breaking the Java API's, giving developers the ability to choose their target platform.
What MS did that wasn't in the interests of either developers or end users was to try to eliminate the option of making portable Java app's, by breaking the Java API's.
"Microsoft's Java support was pretty damn good. It just wan't what Sun wanted."
Well, it wasn't what _anyone_ other than Microsoft wanted. That is, by default with with no warnings, it was very easy for your Java would become Windows-dependent, undermining the fundamental value of Java.
Microsoft could have done all of the innovative things (e.g. calling OS-specific COM objects and other routines easily, nice fast JVM) that they did with their JVM and runtime _without_ violating their Java license, simply by placing their OS-specific enhancements outside of the java.* class heirarchy, by warning developers when they were generating non-portable code, and by supporting all of Java properly. But MS decided that it was more important to try to tie Java developers to Windows than it was to honor the Java license (or, of course, to provide what Java developers wanted).
You mean, like using a public source code control system? There are zillions of projects that use CVS repositories for allowing many people to contribute to the project freely, but there's usually a bit of a process to getting permission to check code in. You do know about the Mozilla project's tools, right? You check code in, and they automatically build the code on all platforms, and run unit tests, and publish the status of the builds on a web page. It's really slick. One of the more subtle bits is that they make broken builds quite obvious (big, red boxes) clearly labeled with the name of whoever did the checkin that broke the build, which produces a strong social pressure to test before checking in, or to fix breakage to get your name off.
Personally, I don't think you'd want to make source code _completely_ publicly writable, because it's more important to keep source code consistent (style, architecture) than text, and the 'submit a patch the maintainer' process does that nicely. But it often takes no more than a simple email exchange to get checkin rights to smaller projects.
"E-voting is insecure and cannot be made secure unless the terminal (computer screen and keyboard) are secure ... PC's do not qualify at all. Any wide-spread worm could targed E-voting for instance"
:-)
I agree that the physical system needs to be secure, but I disagree that PC's can't be secured. For example, the OVC's solution is that the PC's should be booted from a certified CD-ROM, so all of the software would come from the CD, not from the hard drive, which would only be used for temporary data storage. Also, the PC should certainly not be networked, and removable media ports secured, so there's no easy way for a virus or worm to propagate into the PC.
These steps limit attacks to individuals modifying individual machines, which would break security seals, and otherwise would be detected by poll workers or detective work if attempted on a large enough scale to be effective in altering an election's results. Since a typical polling station records 70 votes in a day, it would take 143 people coordinating to modify enough voting stations to potentially affect 10,000 votes.
And of course, since in the OVC's system the physical ballots are the actual votes, not any digital records, and those ballots are visually inspected by voters before they are cast, compromising the voting stations wouldn't affect the results of the election. This is because even a small percentage of voters checking their ballots would detect any cases of stations mis-printing ballots. And any station that consistently mis-printed ballots (easy to verify) would be removed from service. Statistics is a wonderful thing. So any hacked voting station would only be able to modify a very small number of ballots and not be detected, which means that the number of confederates, and thus the chances of one getting caught, skyrockets. For example, if each hacked polling station only shifted 10% of its printed ballots, that would almost certainly be detected by voters, and on top of that would requite 1,428 confederates to coordinate to install the modified software without any of them getting caught. This is why paper ballots are such a great idea.
"And you need to identify yourself first, so you need an electronic ID or suchlike first"
Actually, due to the requirement that voting be universal, it's illegal to require voters to have any particular form of ID. For example, you can't require a driver's license, because non-drivers can vote. So about all they can check is that your name is on the voter roll, so that you only vote once. Yes, this means that you can go to many polling stations and vote multiple times, but the courts have been very consistent that it's more important to allow everyone to vote than to block fake voters. (of course, poll workers may recognize anyone who tries to vote multiple times in the same location, etc.). Beyond that, it's very important that votes be anonymous so that there's no way to determine how someone voted, because that protects voters from intimidation. So you can't record the voter's ID, or even the timestamp of the vote (since someone could record the times that people enter and leave polling stations, and thus derive your votes). This is why paper ballots are shuffled before they're counted.
Voting is harder than it looks.
"someone should create a good Internet voting mechanism, and keep it anonymous yet feasible"
Someone's creating a good eVoting mechanism, the Open Voting Consortium. Go to http://www.openvotingconsortium.org and help out!
I'll also point out that internet voting is fundamentally insecure, but any vulnerability can be exploited infinitely. When voting takes place in polling stations (i.e. offline and under observation), the poll workers can limit the damage of any vulnerability, because they can see who comes in, control who goes into voting stations, for how long, and can stop anyone doing anything too obvious (e.g. unscrewing the voting stations and modifying their internals, for example). Also, internet voting makes any a reliable audit impossible, because there's no voter verified physical record of a vote.
Just to address one misleading claim: "voter-verified paper record would force voters with disabilities to go back to using ballots that provide neither privacy nor independence, thereby subverting a hallmark of the HAVA legislation." This is not true of any well designed Voter Verified Paper Ballot system. There are several commercial voting systems from smaller companies that produce printed ballots without losing voter privacy or independence. And of course the Open Voting Consortium has implemented an open source eVoting system that allows for voters, including those with with disabilities, to use touchscreens or keyboard to enter their votes (thus eliminating invalid ballots, providing for spoken, multi-lingual prompts, etc.). The system prints paper ballots that the voter can verify, both by visual inspection and by running the ballot through a stand-alone verification station (i.e. that can read the ballot back for the voter to listen to). The paper ballot is the vote, which is counted using scanners, then stored for auditing and/or recounting.
That BestBuy link doesn't work. Could you re-post?
"From the NYT article: 'Before saving a digital song to the hard drive, software can shrink it in size by 50 percent or so just by using a shorthand notation that takes up a little less space for any repetitive patterns in the 0's and 1's.' The author of this article shows no understanding of signal processing or how music data is compressed, so his conclusions are silly. Comparing lossy music compression to 8-track tapes is silly."
... If you're saving recorded music, you are always losing data."
Actually, that's a pretty good non-technical explanation for lossless compression.
And the comparison to 8-track makes sense -- it's a lower quality format that was sold as a more portable but lower quality alternative to the LP, analogous to lossy compression is sold as a more portable but lower quality alternative to CD's.
"saving signal data (like photos or music) is always a lossy process, because there no exact digital representation of them"
Of course, going from analog to digital will always (in theory) lose some analog data. But that's sampling, and has nothing to do with compression. You might as well argue that nobody will listen to CD's because of the lost harmonics. Yes, you'd be technically right about the sampling artifacts, but in practice you'd be completely wrong, because CD's sound just fine.
"You decide to save a certain amount of data, let's say, 3 megabytes (or 30 megabytes) for 3 minutes of music, and then you decide what to put in those megabytes. You will always be able to get more/better data into the same space if you use signal processing compressors than if you just use uncompressed samples saved at some sampling rate and width per sample.
This makes no sense. If you've got a digital master, you can't put more/better data into the same space, because you don't have any better data. You can compress the master about 2:1 using lossless compression, because it turns out that there are more efficient ways to encode a pattern (based on repetition, etc.) that are mathematically identical, so you save space without losing any data at all. So I don't know what the 'always losing data' is supposed to me.
You are right, though, that in lossy compression schemes, the CODEC's try to optimize the use of the available bits to minimize the perceived loss of quality.
You should listen to low bit rate AAC+ some time. It's f-ing amazing what people can get out of a 32 Kbps bitstream.
"Unbelievably, any person with a PC and an Internet connection can now logon to the NSA's website and print out the blueprint for NSA s Security Enhanced Linux software."
They say that like it's a bad thing. I suppose it's so obvious it hardly bears stating, excpt that obvious a few people missed it, but in practice a system that is open to inspection is more trustworthy than one that's "secret" because it's better tested. This is one reason that BSD is so much more secure than Windows, Apache is so much more secure than IIS, etc.
"I blieve the 25 Tflop figure is a typo. I've read 15Tflop elsewhere ... they're also using plain gigabit ethernet for interconnects, not Infiniband, supposedly because the applications they plan to run don't require a lot of I/O"
Now _this_ makes sense. I can easily believe that a different app could have very different performance characteristics, which could explain a 2x performance difference. That won't affect the Top 500 list too much, though, since it's based on standard benchmarks.
In any case, it's nice to see another Mac supercomputer. It's kinda cool watching the open source world win (since an Xserve is basically an open source machine as far as supercomputing nodes go -- nobody cares about the GUI on a compute node) that's competitive based on raw performance. Go PPC!
"Had you read the article you would have known that thr Army machine is connected using standard gigabit ehternet whereas the Big Mac used Infiniband."
f ) than Infiniband. That is, unless there's some sort of magic router involved, I don't see how GigE would make CPU's faster.
GigE is about 10x slower (for this type of networking, see http://www.infinicon.com/pdf/LSTCUG-2003-Final.pd
Perhaps they're measuring different applications, and the Army machine doesn't need much communications? Kinda an odd way to benchmark...
This sounds like a killer system, but I don't follow the performance numbers.
The 1655 CPU cluster is expected to deliver 25 Tflops, while the Virginia Tech machine, with 1,100 CPU's (if I remember properly) is rated at 10 Tflops. What else is different? Are they using a different interconnect? Clever programmers to get closer to peak? Or is it something silly like a journalist switching between peak and measured performance, or between computers and CPU's (assuming dual G5 Xserves)? Or is the G5 Xserve really _that_ much faster than the G5 desktop measures VA Tech was benchmarked with? I _like_ that idea...