Slashdot Mirror
Slashback: Centrinissimo, Damages, Software
Formalization schmormalization. kaisyain's review today of Software Craftsmanship raised a spirited conversation about the nature of software, software engineering, and related disciplines. cconnell conveniently submits a great companion piece: "I wrote this article a couple years ago but it has continued to get good readership within the software engineering community. Should provoke some interesting discussion..."
The bleeding edge costs money. JeffyVernon writes with an followup to CNET's early review of Centrino laptops: "AnandTech published two articles on Centrino today, an overview of the CPU architecture (including some interesting history behind the chip) and a roundup of four notebooks including the new Dell that wasn't in CNet's roundup. It looks like the 4.9lbs IBM T40p ended up winning the roundup, it lasted over 6 hours on battery!"
What scarcity was this exactly? RadBlock writes "Lawrence Lessig is addressing the issue of radio spectrum on CIO Insight... something that was talked about on Slashdot the other day. Lessig states that the spectrum has been defined too generally as if there can only be one message per frequency, when better equipment will vastly increase the amount of 'spectrum' that is usable."
I like that phrase "general welfare." We've mentioned eGovOS several times before -- now, here's a last-minute announcement that may be of interest: free registration is still open for next week's (March 17-19) eGovOS conference in Washington D.C., "Open Standards/Open Source for National and Local eGovernment Programs in the U.S. and EU." Perhaps some folks there ought to consider the question eugene ts wong raised the other day, namely, Which North American government offices won't move to Linux? Someone needs to set up a big map with different colored countries and states!
Who's laughing and where is his bank? deelowe writes "From ars. Back in September we reported on a class action suit leveled at a number of Music industry players that accused them of anti-competitive price-fixing. Back in January, we reported that victims of said price fixing could hit this website and sign up (too late now), and eventually receive up to $20 in the settlement, provided of course that you had actually purchased a CD between January 1 1995 and December 22, 2000. 3.5 million Americans made their way to the on-line form, and it appears that victims will receive $12.60 apiece, should a judge approve it."
They still have a while to go ... sp1nl0ck writes CNet News.com.com.com are reporting that The Neo Project guys have restarted the attempt to crack the 2048-bit XBox key following advice from their lawyers. CNet are citing a link to Operation Project X, but it was a bit temperamental in loading earlier. Maybe it's been CNetted..."
I'll still think of it as the GIMP for a few years ;) Agermain writes "CinePaint has just released its first Windows build. From their website: "CinePaint is an open source painting program used by motion picture studios to retouch images in 35mm films. It was formerly called Film Gimp. It has been used in a dozen feature films including Harry Potter, Scooby-Doo, and the Fast & the Furious... This first Windows beta release is mainly intended for developers and testers.""
The victims will receive $12.60 each.
The lawyers will receive $20 million each.
There's no justice like american justice!
Ya baby!
Donate it to the guy that runs Kazaa Lite.
Sounds like a bargain! In exchange for a paltry $50M, they now have a confirmed list of 3.5 million music consumers, their names, email and physical addresses, birth dates, and last 4 digits of their social security numbers. I wonder how much they'll be recoup by reselling that list, or just using it themselves.
As much as I wanted to see the RIAA's wrists slapped for being naughty, it felt like *I* was going to be the one to suffer if I filled out that form.
pcmag has another review, this includes Dell and Acer. Dell D600 is recommended choice (performance/price balance). An interesting detail is that Dell did not use MS 802.11 component but something else, and they have achieved the best results in 'wireless' part of the test. Seems like the wireless part of Centrino is mediocre or worse.
One less hour of battery life, but the Pentium-M is faster than an equally-clocked Pentium 4. The Crusoe would be a fraction the speed of the Pentium 4 yet that only buys you an extra hour of use. I think Transmeta is in _big_ trouble unless they've got something better up their sleeve.
Good lord. We're supposed to be geeks here, right? Let's do the math on this.
The Xbox uses a keyspace of 2^2048. So far, the project has manage to do a little over 17 billion keys, call it 2^34 keys. That means, they have managed to test roughly fuck all. If Microsoft sent a negative result back for the actual key, the chances are higher that a couple of inopportune cosmic rays would change the result to positive, than they are that these guys are going to test even 3*(fuck all), before people figure out that the method is hopeless. Vague mumblings on their site about "a chaos thing" does not make brute force search in that sort of keyspace any less hopeless.
You can make $10,000 by solving a problem that's 1/(2^1472) as difficult by cracking RSA-576. Why are we paying attention to these guys?
When the world of personal computing was young, and new compression utilities seemed to be coming out every week, every so often you'd hear someone claim that they'd achived the holy grail - written a compression program that could compress its own output, or compress arbitrary files 100x, or perform some other impossibility. Wise people didn't believe them, because information theory strongly limits your ability to compress arbitrary data.
In recent years, we've started hearing similar claims about the spectrum. Remember when impulse-based signal transmission was going to give us limitless bandwidth? This is more of the same.
First, I'll explain the limits to transmission bandwidth. Then, I'll explain how Mr. Lessig is planning to get around them. Finally, I'll explain why it doesn't work.
The spectrum, at the location of any given broadcast transmitter or broadcast receiver, is limited. The bandwidth - range of frequencies - available is fundamentally limited by the receiver's sampling rate (or frequency cutoff, for analog signals). There is no way to get around this, short of using more of the spectrum (by having a higher frequency cutoff). In the past, it was difficult to access even this much, due to the nature of the electronics used (response wasn't perfect, filtering wasn't perfect), but modern electronics are much better (as Mr. Lessig points out in his radio airplane example). The bandwidth limit, however, remains.
The amount of information you can transmit within a given region of the spectrum doesn't depend solely on the bandwidth - it depends on both the bandwidth and the fidelity of your sampling within the band of interest (how many levels you can decode without noise if you're quantizing, or what your signal-to-noise ratio is if you're using a fully analog system or a digital system with very high fidelity). The number of bits of information you can stuff into a spectrum region per second is the log to the base 2 of the number of levels you can reliably distinguish from each other.
This limit applies to any limited-bandwidth signal, regardless of the encoding scheme used. Use spread-spectrum transmission to smear a narrow-band signal over a wider region of the spectrum, and the limit just tells you how many signals you can broadcast this way before the noise floor swamps all signals. The mention of spread-spectrum transmission in the article is a red herring - it doesn't gain you data capacity (it's used for other reasons).
If your system is purely a broadcasting one - sending in all directions, receiving in all directions, no wormholes or relays - this is the best you can do.
You can improve the situation somewhat by trying to beamcast messages instead of broadcasting them. However, this still has problems. Firstly, your "beam" is really a cone. Secondly, your transmitter/receiver is larger, as you need a dish or a carefully shaped antenna or a large array of antennas and some signal processing to get direction-selectivity. Both are caused by diffraction limits related to the wavelengths of the signals being used - a fundamental process that can't be avoided. Thus, while it's used for transmitters (take a look at a cell tower some time), it's not practical for receivers. Either way, you end up with a fixed, finite gain in capacity, as the narrowness of a transmitter's beam can't be made smaller than a certain amount without requiring an extremely large transmitter.
So what about the idea of having short-range transmitters/receivers, and relaying between them? Well, this works to some extent. However, you must have a non-broadcast backbone. Solely relying on the short-range units for signal relaying bogs down very quickly. Consider an area with transceivers uniformly distributed in it, with source and destination points for any given communication chosen at random. Draw a line through the middle of the region. With N transceivers, the number of signals crossing the boundary goes up as O(N), but the number of nodes on the boundary that can do
Here's my suggestions:
everyone who receives their $12 check DONATE IT to the EFF right away - what a great gesture, and what a great fundraising opportunity.
In short, there is a software engineering field, because there's a field that applies scientific knowledge to solve practical problems. Yes, the science is immature. A great deal of the current information consists of rules-of-thumb based on statistical analysis of past projects. (e.g., cost and schedule models). But that's how many other engineering disciplines started too.
Computer scientists are necessary to identify the basics, just as physicists and chemists are needed to identify fundamental scientific properties needed to build a bridge. But physicists and chemists shouldn't be designing or building bridges, unless they are also engineers. You need people who can bridge the gap between the science and the problem to produce an answer.
- David A. Wheeler (see my Secure Programming HOWTO)
In the sited article, the author makes his most critical point:
"The precision of traditional computer science has a drawback, however. The problems that are solved are those that are amenable to precise solutions. These problems are, by definition, tightly defined, with no mushy statements or an unacceptably high number of variables. In short, these problems are easier than real-world problems that aren't conveniently narrowed."
This says it all to me. In reality, systems design and the resultant programming implementation are truely a mixture of Art and Science.
Software is made for people to use - either directly, such as a productivity application on a personal computer - or indirectly, such as a program embedded in a microprocessor in a car. As people become more sophisticated in their use of software, they expect software to do things that come naturally to people. This makes programs more complex, and provides situations that sometimes can not be well defined in advance, or ever over the life of the application yet still needs to be adressed in the program!.
If we, as computer scientists, force the definitions of problems to fit neatly within acceptable scientific boundaries, we invariably produce a product that is unusable by human beings over the long run. I see this in the real world all of the time; development teams that insist that every aspect of the specification be written before coding is accomplished - and once coding starts, no changes are allowed (this is commonly referred to as the 'waterfall' lifecycle - i.e. - design, spec, build, maintain, deprecate - a one path solution).
As a developer/programmer, I have been advocating a more holistic view of software development. We, as programmers, are not here simply to satisfy our own egos; we are here to help people through our work. If there were no people there would be no need for software, as tautological as this sounds, it is indeed true, and something programmers should think about every day.
Along these lines I advocate an iterative lifecycle model (and you will see similar ideas called other things, such as the 'ready, shoot, aim' approach of software design as put forward in the 'Pragmatic Programmer' [don't have the author's names or the publisher...sorry]
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain