Sounds like some more people should read Brooks' Mythical Man Month. There's a reason this 40-year-old book still inhabits my bookshelf at work.
'Course, from how EA seems to treat their programmers, it sounds like they're not really considering any human aspects of the cycle, so I suppose this is not surprising.
Well, I'm not sure if it's that nobody read the article, or if nobody actually understood it, but.
We've had a lot of posts about "OH NO! COBOL!" Yes, yes, I agree with you -- pretending to be English usually results in awkward and unnatural syntaxes. One of the advantages of a formal syntax like most programming languages is that it clicks the brain into a different mode. (How many of you can read sigs like 2b||~2b? I thought so.)
But that's not really the paper's main aim. It makes a couple of notes that all of us, particularly those of us in language design, could benefit from.
1. People tend to deal with collections in the aggregate far more often than they step through them an item at a time. The example given was "set the nectar of all the flowers to 0." Look past the syntax for a moment and look at how simple that is.
2. Debugging the traditional way sucks. Did anyone actually read that bit at the end about the 'Why?' questions, and look at the screenshots? Holy crap. That's really impressive.
Of course, I may be biased, because the points made in the article are basically the same that underlie a language I'm currently designing.:-) (And no, I'm not using Englishy COBOL syntax.)
It's that many programmers are so goddamn individualist. (Speaking as a programmer, I see some truth in this.) The reaction is typically something like "Why should I team up with you? I can do this on my own." And then, of course, they don't.
It's sort of a sociopolitical not-invented-here syndrome; I see it as directly connected to the number of started-but-unfinished projects on Sourceforge that do exactly the same thing.
The title of this article may be misleading for those who equate "e-voting" with "touchscreen machines."
The machine that failed was an optical scan machine. This is like a scantron for school exams; it's the type we use here in Arizona. You fill in little arrows and it reads which ones are darkened. There are still paper ballots that go into a lock box under the machine.
Personally, I don't think this is "e-voting" at all and that the title is just plain wrong, but since optical scan machines do, indeed, use electrons, I suppose it's arguable.
I know this is not the best place to say this, but:
Hey! Mac developers! Quit requiring privileged steps during install!
Seriously. The Mac app architecture is designed so you can put all your files into a single bundle without littering crap all over the user's system folders.
I, for one, tend to kill any install that asks for my admin password (which is why I'm still using Preview instead of Adobe Acrobat).
If people get used to entering their admin password on every damn install, trojans like this will be all too easy. It's like software requiring a root install on Unix -- it's suspicious.
You take this USB key and plug it into an untrusted machine (since, if you had a trusted machine, you wouldn't have to go through these hoops). It fires up a virtualized PC that runs Linux and lets you get out to the web using an encrypted proxy.
I fail to see the utility of this. You're running QEMU on the host. If the host is compromised (and it's best to assume that any untrusted host is), it has full access to your keystrokes, I/O, and the entire memory image of your system.
Good crypto software for Unix makes sure to prevent its sensitive data from going out to swap by negotiating with the virtual memory system. This keeps your passphrases and keys from showing up in a swapfile if the machine is compromised. This type of system has no control over that -- if the host decides to swap the emulator out, foom! your entire system image is now on disk. A disk you don't trust.
Not to mention that processes on the host could simply read through your memory in real time.
So, in short, an untrusted computer is still an untrusted computer. While this sounds useful for encrypting one's network connections, it seems like an awfully complex solution to reinvent the concept of a VPN.
Or he may have simply been referencing Beowulf, which was, fundamentally, just an adventure novel.
If Beowulf were written today, it wouldn't merit study for those who don't like Stephenson's "Beowulf writers." (And not just because everyone would say "You just rewrote Beowulf.":-) )
The new for loop most certainly is syntactic sugar. It's taking something we could do before and shortening it into a new construct.
However, a lot of folks use 'syntactic sugar' as a derisive term. It's not. It saves programmer time. Generally the times that it's bad are when it's (a) hiding what's really happening to a degree that introduces bugs, or (b) misguided, like SQL's attempts at being English-like.
If the two cores have a shared cache (as IBM's multi-core POWER chips do), any given word must only be in cache once and can be accessed by both cores. If the chips are separate dies on the same chip (with their own caches), or separate chips on the motherboard, you can wind up with a lot of redundant data in the caches.
I don't remember if Intel's supposed multi-core chip has a unified cache architecture or not.
I definitely wouldn't put the faked demo past them, however -- tech companies do this all the time. In this case, it could be "Look! We have dual-core processors too! Please continue buying our stock!"
It's pretty neat -- used to use it to bind my laptop and desktop screens at the office.
I ran into some issues with unsupported server extensions, if I remember correctly -- but that might have been something else around the same time.
My main issues with it were difficulty of setup (high), speed (medium), and lack of dynamic configurability. That is, it would be more useful to me if I could add and remove displays without exiting my entire X session.
I should clarify. If your master (the one with the kbd and mouse) is Windows, use the aforementioned win2vnc package (or equivalent) with, for example, the vnc X module to allow control of your existing session.
I typically set the X box as master and send VNC events to the Windows box or Mac, though.
If the master machine is X and the slave is not, use x2vnc.
If you have a different config, google for one of those terms and use the Windows package (I have no experience with it, but I think it's called something creative like win2vnc.)
SD's interface is vastly faster than MMC (stock MMC anyway, there's the new something-X MMC cards that are supposedly faster). There was, at one time, also an interface size limitation that kept MMC cards capped at (iirc) 64M, but that seems to have been resolved. (Prolly protocol changes.)
SD also includes encryption and some sort of auth so your music will be "safe" (hence the Secure in Secure Digital). This is why us Linux folks are having a hell of a time with it, because on e.g. the iPaq we can't take full advantage of the slot. (The SD folks would rather not open-source their encryption, which, to me, points to a certain degree of ignorance about encryption.)
It's powered by these little replaceable compressed air cartridges, each one with an embedded chip to authenticate it to the helicopter. When it runs out, you gotta replace it.
You might think you could just refill it, since air is cheap, but no! The chip won't let you!
Don't try to reverse engineer the air cartridge, Epson will beat you with the DMCA-stick.
Most of the comments so far have been along the lines of "UNISYS IS TEH EV1L!!!" but I'll break from the trend.
The dynamic partitioning stuff strikes me as very useful. I'm on some large Solaris machines here with static partitioning; if the Unisys boxen can shuffle CPUs around to adapt to load, that'd be pretty damn cool.
They might actually have some interesting products to offset their general cluelessness.
And, of course, there's the fact that his latter two complaints are kind of sort of fixed in 1.5.
So...:-)
Personally, I think the C# folks make too much of a big deal about the mandatory exception handling in Java. Heard a fellow from Microsoft say "Frequently, Java folks just put an empty catch() block to catch the exception they know won't happen, so why make it mandatory?"
I've got bad news for you. I find situations like that about once a week when auditing my programmers' code, and it's almost always a situation that -can- happen, but the programmer couldn't see it.
While I agree with most of what you say, I had a couple notes I wanted to make:
1. On half-terabyte RAID arrays: keep in mind that one can fit 800GB in two 3.5" half-height bays these days. Compressed losslessly, that's a hell of a lot of music. (Based on my own experience with FLAC getting songs to 33-40% of their original size, I'd estimate 3510 full CDs.)
2. On the content, Starbucks is already pushing a lot of indie or pseudo-indie jazz, blues, and world content. They've got the content to draw on, and it's diverse, if niche. Moving this off of CD inventory into an on-demand system could actually save them money, not to mention increase selection (and, presumably, sales).
Yeah, I was trying to distinguish between 'broadcast' IP traffic (in the sense of traffic sent to the subnet broadcast address) and multicast. Multicasts are sent to specific group addresses, making them relatively easy to filter by type or group, or to route between networks.
In our case, we handle routing of some Rendezvous traffic across several subnets filtered by type (specifically, iChat and service discovery) using simple pf rules. Doing that for specific kinds of, say, NetBIOS (broadcast-based) would be a pain.
Actually, this doesn't help in creating iTunes-compatible clients.
The Rendezvous protocol specs have been available for some time (it is, after all, a combination of IETF standards). There are compatible implementations for many platforms; on Linux my favorite has been Howl, but JRendezvous is nice too.
iTunes itself uses a proprietary protocol that Apple keeps changing. Parts of it are well-understood (like the music directory portion) but others are not (like the streaming).
Interestingly, Apple is willing to release these docs to developers under NDA. I went through the process but got rejected when they discovered that my product is open-source (even though the iTunes component was to be a binary-only plugin). Apparently they're twitchy about mixed-license developers bending to community pressure and releasing their proprietary info.
Which, with all the GPL bigots I deal with day-to-day, I can kinda understand. Kinda.
Slashdot Mirror
Sounds like some more people should read Brooks' Mythical Man Month. There's a reason this 40-year-old book still inhabits my bookshelf at work.
'Course, from how EA seems to treat their programmers, it sounds like they're not really considering any human aspects of the cycle, so I suppose this is not surprising.
Well, I'm not sure if it's that nobody read the article, or if nobody actually understood it, but.
:-) (And no, I'm not using Englishy COBOL syntax.)
We've had a lot of posts about "OH NO! COBOL!" Yes, yes, I agree with you -- pretending to be English usually results in awkward and unnatural syntaxes. One of the advantages of a formal syntax like most programming languages is that it clicks the brain into a different mode. (How many of you can read sigs like 2b||~2b? I thought so.)
But that's not really the paper's main aim. It makes a couple of notes that all of us, particularly those of us in language design, could benefit from.
1. People tend to deal with collections in the aggregate far more often than they step through them an item at a time. The example given was "set the nectar of all the flowers to 0." Look past the syntax for a moment and look at how simple that is.
2. Debugging the traditional way sucks. Did anyone actually read that bit at the end about the 'Why?' questions, and look at the screenshots? Holy crap. That's really impressive.
Of course, I may be biased, because the points made in the article are basically the same that underlie a language I'm currently designing.
As someone who's tried, it's not that at all.
It's that many programmers are so goddamn individualist. (Speaking as a programmer, I see some truth in this.) The reaction is typically something like "Why should I team up with you? I can do this on my own." And then, of course, they don't.
It's sort of a sociopolitical not-invented-here syndrome; I see it as directly connected to the number of started-but-unfinished projects on Sourceforge that do exactly the same thing.
Libertarian, huh?
I have to assume you checked the type of the file by pointing at it in the Finder.
Pull up a Terminal and enter 'file name-of-one-of-the-files' without the quotes. It will tell you.
It's likely to say DICOM Medical Imaging Data, but we'll see.
Search for a reader for the format it suggests.
The title of this article may be misleading for those who equate "e-voting" with "touchscreen machines."
The machine that failed was an optical scan machine. This is like a scantron for school exams; it's the type we use here in Arizona. You fill in little arrows and it reads which ones are darkened. There are still paper ballots that go into a lock box under the machine.
Personally, I don't think this is "e-voting" at all and that the title is just plain wrong, but since optical scan machines do, indeed, use electrons, I suppose it's arguable.
I know this is not the best place to say this, but:
Hey! Mac developers! Quit requiring privileged steps during install!
Seriously. The Mac app architecture is designed so you can put all your files into a single bundle without littering crap all over the user's system folders.
I, for one, tend to kill any install that asks for my admin password (which is why I'm still using Preview instead of Adobe Acrobat).
If people get used to entering their admin password on every damn install, trojans like this will be all too easy. It's like software requiring a root install on Unix -- it's suspicious.
Okay, lemme get this straight.
You take this USB key and plug it into an untrusted machine (since, if you had a trusted machine, you wouldn't have to go through these hoops). It fires up a virtualized PC that runs Linux and lets you get out to the web using an encrypted proxy.
I fail to see the utility of this. You're running QEMU on the host. If the host is compromised (and it's best to assume that any untrusted host is), it has full access to your keystrokes, I/O, and the entire memory image of your system.
Good crypto software for Unix makes sure to prevent its sensitive data from going out to swap by negotiating with the virtual memory system. This keeps your passphrases and keys from showing up in a swapfile if the machine is compromised. This type of system has no control over that -- if the host decides to swap the emulator out, foom! your entire system image is now on disk. A disk you don't trust.
Not to mention that processes on the host could simply read through your memory in real time.
So, in short, an untrusted computer is still an untrusted computer. While this sounds useful for encrypting one's network connections, it seems like an awfully complex solution to reinvent the concept of a VPN.
Or he may have simply been referencing Beowulf, which was, fundamentally, just an adventure novel.
:-) )
If Beowulf were written today, it wouldn't merit study for those who don't like Stephenson's "Beowulf writers." (And not just because everyone would say "You just rewrote Beowulf."
I both do and do not agree with this.
The new for loop most certainly is syntactic sugar. It's taking something we could do before and shortening it into a new construct.
However, a lot of folks use 'syntactic sugar' as a derisive term. It's not. It saves programmer time. Generally the times that it's bad are when it's (a) hiding what's really happening to a degree that introduces bugs, or (b) misguided, like SQL's attempts at being English-like.
I think this might well be the first time, in my memory, that a company has released an upgrade to an OS that's more or less unreleased.
Sure, you've been able to run OS6 on an emulator for about a year now, but there have been a grand total of zero OS6 devices released.
But, hey, at least we can all go upgrade our emulators!
Many of us call that "Unix."
If the two cores have a shared cache (as IBM's multi-core POWER chips do), any given word must only be in cache once and can be accessed by both cores. If the chips are separate dies on the same chip (with their own caches), or separate chips on the motherboard, you can wind up with a lot of redundant data in the caches.
I don't remember if Intel's supposed multi-core chip has a unified cache architecture or not.
I definitely wouldn't put the faked demo past them, however -- tech companies do this all the time. In this case, it could be "Look! We have dual-core processors too! Please continue buying our stock!"
It's pretty neat -- used to use it to bind my laptop and desktop screens at the office.
I ran into some issues with unsupported server extensions, if I remember correctly -- but that might have been something else around the same time.
My main issues with it were difficulty of setup (high), speed (medium), and lack of dynamic configurability. That is, it would be more useful to me if I could add and remove displays without exiting my entire X session.
I should clarify. If your master (the one with the kbd and mouse) is Windows, use the aforementioned win2vnc package (or equivalent) with, for example, the vnc X module to allow control of your existing session.
I typically set the X box as master and send VNC events to the Windows box or Mac, though.
Yes, it exists.
If both machines are X-windows, use x2x.
If the master machine is X and the slave is not, use x2vnc.
If you have a different config, google for one of those terms and use the Windows package (I have no experience with it, but I think it's called something creative like win2vnc.)
Because, if there's any industry that's bent over backwards to inspire customer loyalty, it's the telecoms. ...
Yet another example of innovation sweeping the market out from under an industry that's too busy screwing its consumers to notice.
SD's interface is vastly faster than MMC (stock MMC anyway, there's the new something-X MMC cards that are supposedly faster). There was, at one time, also an interface size limitation that kept MMC cards capped at (iirc) 64M, but that seems to have been resolved. (Prolly protocol changes.)
SD also includes encryption and some sort of auth so your music will be "safe" (hence the Secure in Secure Digital). This is why us Linux folks are having a hell of a time with it, because on e.g. the iPaq we can't take full advantage of the slot. (The SD folks would rather not open-source their encryption, which, to me, points to a certain degree of ignorance about encryption.)
It's powered by these little replaceable compressed air cartridges, each one with an embedded chip to authenticate it to the helicopter. When it runs out, you gotta replace it.
You might think you could just refill it, since air is cheap, but no! The chip won't let you!
Don't try to reverse engineer the air cartridge, Epson will beat you with the DMCA-stick.
Most of the comments so far have been along the lines of "UNISYS IS TEH EV1L!!!" but I'll break from the trend.
The dynamic partitioning stuff strikes me as very useful. I'm on some large Solaris machines here with static partitioning; if the Unisys boxen can shuffle CPUs around to adapt to load, that'd be pretty damn cool.
They might actually have some interesting products to offset their general cluelessness.
So, following this hypothesis, the tools for the Brainfuck programming language should be best of all? I've -never- seen a BF job posting.
And, of course, there's the fact that his latter two complaints are kind of sort of fixed in 1.5.
:-)
:-)
So...
Personally, I think the C# folks make too much of a big deal about the mandatory exception handling in Java. Heard a fellow from Microsoft say "Frequently, Java folks just put an empty catch() block to catch the exception they know won't happen, so why make it mandatory?"
I've got bad news for you. I find situations like that about once a week when auditing my programmers' code, and it's almost always a situation that -can- happen, but the programmer couldn't see it.
Don't trust the programmer. I know, I am one.
While I agree with most of what you say, I had a couple notes I wanted to make:
1. On half-terabyte RAID arrays: keep in mind that one can fit 800GB in two 3.5" half-height bays these days. Compressed losslessly, that's a hell of a lot of music. (Based on my own experience with FLAC getting songs to 33-40% of their original size, I'd estimate 3510 full CDs.)
2. On the content, Starbucks is already pushing a lot of indie or pseudo-indie jazz, blues, and world content. They've got the content to draw on, and it's diverse, if niche. Moving this off of CD inventory into an on-demand system could actually save them money, not to mention increase selection (and, presumably, sales).
Yeah, I was trying to distinguish between 'broadcast' IP traffic (in the sense of traffic sent to the subnet broadcast address) and multicast. Multicasts are sent to specific group addresses, making them relatively easy to filter by type or group, or to route between networks.
In our case, we handle routing of some Rendezvous traffic across several subnets filtered by type (specifically, iChat and service discovery) using simple pf rules. Doing that for specific kinds of, say, NetBIOS (broadcast-based) would be a pain.
Actually, this doesn't help in creating iTunes-compatible clients.
The Rendezvous protocol specs have been available for some time (it is, after all, a combination of IETF standards). There are compatible implementations for many platforms; on Linux my favorite has been Howl, but JRendezvous is nice too.
iTunes itself uses a proprietary protocol that Apple keeps changing. Parts of it are well-understood (like the music directory portion) but others are not (like the streaming).
Interestingly, Apple is willing to release these docs to developers under NDA. I went through the process but got rejected when they discovered that my product is open-source (even though the iTunes component was to be a binary-only plugin). Apparently they're twitchy about mixed-license developers bending to community pressure and releasing their proprietary info.
Which, with all the GPL bigots I deal with day-to-day, I can kinda understand. Kinda.