Remember that there were those of us doing real work on Cisco and SunOS that paid the bills, including all the money that the web group squandered, back when internet meant the home office LAN and all the field offices linked together, not some dot-bomb fairyland.
I don't doubt that there are real pikers in many IT departments, but in the one I work in, there are very few. We were, however, subjected to a rotating collection of child "web designers" who knew fuckall outside of VB script and could have cared less about anything that they couldn't put into their Palm Pilots in under 30 seconds.
As for security, about half their sites (hosted externally) were owned in a week long period. Even after that they wondered why wouldn't let 'em run NT boxes open to the world.
Heh, I've seen (participated in?) the IT vs. Web development wars and it's not a good idea to have Web as a client of IT because IT is usually pissed/jealous/scared/disgusted at/of/at the Web group for many of the same reasons that the Web group can't stand IT.
I was on the IT side, and we had a shitpile of varied systems and thousands of end user computers to keep running *securely* and in whatever harmony the software would allow, within our budget, and within the complex politics that is most corporations. A complicated job by itself.
The web people I worked with were usually nice, I even respected some of them. But they didn't get the big picture of the total environment as well as we (tried to) do, and they were always at the bleeding edge of everything and were pissed because we wouldn't do massive client-side upgrades every time there was a.001 rev of some plugin or why we woudln't run machines with no security, hand out root passwords, etc.
I'd agree with you that they need to be seperate, in fact I'd vote for totally seperate -- like in another building across town. I think better web sites (better interop, better functionality, etc) comes from not even dreaming about having any influence or control over the desktop environment.
But then, as others have pointed out, is the cost of the box, the manual. But those are just the manufacturing costs. You're leaving out entirely the management cost. Somebody at MS, presumably an entire department, has to supervise the manufacturing and distribution (itself another cost) of packaged software.
I'd guess that it costs MS at least $2M per year to have a small staff that supervises the production of XP boxed software. That's salary, benefits, office space, phones, coffee, scotch, hookers, hush money and everything else that it costs MS to have those people do the job of seeing that someone else makes CDs, prints manuals, shoves them into boxes and gets 'em trucked to the local Microcenter.
It's those numbers along with the manufacturing costs that gives MS their per-unit numbers.
despite the fact that sci-fi viewers are more intelligent than soap opera viewers
Heh, just because you think that soaps are stupid that doesn't mean that all soap viewers are stupid. It may be that soap viewers are very intelligent, but their intelligence is focused on relationships and emotions and psychological motivations rather than technology.
Personally I think that SciFi is most interesting when positing social questions (Philip K Dick, Ray Bradbury or even Heinlein) or when doing the aliens and gadget routine (Star Wars, etc). I think its weakest when it tries to focus on character development. I have yet to see characters in mainstream scifi get developed beyond the cardboard cutout stage. If I want good human interest (eg, people and social situations are the focus), I'll read someone who's a real fiction writer.
Complexity doesn't necessarily make a good narrative. Most of what are regarded as the best narritives are often very simple and easy to understand. Take Shakespeare for example -- there are very few storylines that don't have a direct parallel to a Shakespeare play, and his plays were written to amuse 16th century Londoners, a group probably much less educated than even today's soap opera viewers.
I think there's good reason for a SciFi TV show to focus on aliens, technology and action and shy away from overly involved narratives and excess character development. Most SciFi writers, when aiming for "deep" narratives make Paradise Lost look like an Archie comic and they're terrible at character development. I can't think of a single Voyager character that was either memorable or even interesting.
Speaking of Soaps, have you ever actually *tried* to watch one? I think they're unbelievably complicated. We tried in college to follow All My Children one quarter (on before lunch, no classes, etc) and found it inexplicable. Yet I've known people (mostly women) who can describe months of plotlines and intricate character motivations. Don't underestimate the soaps.
They probably do view it that way, but a lot of places would rather reap rewards with zero input, which has always been the bugaboo of open source development or any other "from each, to each" kind of economic model.
If every shop with more than 20 programmers donated 1 FTE of programming time to some centralized open source collective, I would imagine that the rewards might be magnitudes beyond what they gave. The question would be how would their time get assigned and who would manage it, both massive political questions.
I've had two recent bubble wrap experiences. Last march I shipped a DLT4000 drive wrapped in about 6" of bubble wrap from MN to CA. When I got to CA, the drive, an old Dec TZ-88 had its metal housing smashed so bad it was bent, and the metal housing on that drive has got to be.125" steel.
The odd thing was that the *box* was totally intact and showed no sign of being opened, crushed or otherwise mangled.
I'm totally at a loss as to what happened to it, it almost seems like it was internal inertia that mangled it because it doesn't seem possible for the damage that drive experienced to happen without the box looking like it had been delivered via howitzer.
I did the same thing again two weeks ago, but this time I wrapped the drive in 12" of bubble wrap (as in the drive plus wrap is now about 32", nearly round) and it survived OK.
I'd like to get some of that plastic and quick setting foam stuff that some things seem to ship with. It looks like you pretty much just spray foam in the box, lay a piece of plastic inside, lay your stuff down, and then lay plastic on top of it and then spray more foam -- totally contoured to match the item and the box.
If you're doing colo hundreds of miles away, it'd make sense to figure out how you want to do OOB management. We use HP servers and they have a great out of band management capability -- power off, on, restart and console-level keyboard and text mode display capabilities independant of the OS. Couple this with a modem and you should be able to handle anything short of a total reinstallation.
Dunno what your colo environment is, but if you're buying a couple of U of rack space you could add one of those serial port management gizmos that does dialup and telnet access to a few serial port for greater flexibility.
That being said, I've had good luck with FreeBSD just doing makeworld and installworld remotely and rebooting without the machine going foobar on me. My drive is like 10 miles and the longest part of the journey is from the parking garage to the machine room, but I haven't had to make it but once due to a stuck management controller (fixed by BIOS upgrade) that required "F2" to continue booting but also locked out out of band management.
The key is being able to whack the box remotely without driving in. Unless you totally screw the OS to the point of reinstallation, most systems with OOB capabilities can get you going when the OS prevents a ssh-type connection.
I've recently been quoted just over $2k per month for a multilink dual T1 connection. The sales engineer told me that beyond 6 T1s it was cheaper to go with fractional DS3. So I figure that $10k has to be buying a lot of bandwidth. I'd guess that it'd be something like 18Mbps, which is a lot of bandwidth.
Still, once you get into DS3 land the local loop has to be crushingly expensive.
It's a mixed bag, but the folks over at AFU claim that this is an old mapmaker's trick. Put nonexistant roads or other geographical features into the map so that if it gets duplicated you know its your map.
I've never found anything like this specifically, although I've gotten plenty lost before (specifically in Louisiana) when the map's idea of the road and the road's idea of the road differed.
I always presumed that this was something of an unintentional trap -- in order to make the map more quickly and easily, Big Name Map Company used a government provided map as a basis for their map and the government map was either wrong or woefully outdated. It usually hapens with county roads or other more rural throughfares.
Considering his racks, why not suggest the SmartUPS 3000RM? Just like the 3000 floor model, but it's rack mountable. The 3U version has a little less power than the 5U one, but they're a hell of a lot more space conscious in a racked environment.
Smarter yet would be getting a Trace power panel and some batteries and running the whole room's electrical system.
Uhhm, there is no such thing as "hardware journalling". It's an oxymoron. By definition, journalling is file system-dependent.
Why is that? A simple version of what I'm thinking of would be a disk controller with two disks attached. One is your real disk the other is the journal disk. Every block level operation would be written twice, once to the real disk, and one to the transaction log with a timestamp.
Clearly any reasonably busy filesystem would require a lot of storage to maintain the transaction log (and maybe that's what would make this impractical for high-volume systems), but how many systems with 100G of disk modify all 100G every day? 100G of disk with 10G of modification per day could be journaled for at least 9 days with an equivilent journal disk.
Speed is a non-issue, IMHO. Any reasonably modern disk array controller can handle mirrored writes with no problem, and this is not much different from mirroring.
Many SAN storage systems have the ability to make snapshot copies of individual LUNs, I was told by one vendor that they were working on the ability to make incremental copies of a snapshot.
Journaling a LUN seems like a logical extension of this ability, and a way to provide fault tolerance.
Are there any disk array controllers or other storage devices that do FS-independant journaling at the block level?
It'd be an interesting way of doing backups -- instead of restoring from tape, you could get the disk controller to back out changes to a specific timestamp.
I'm sure there are some gotchas -- without knowledge of the filesystem, a specific hardware level transaction may not have complete filesystem level coherency, for one. And it may take a lot of disk to keep a log of any decent duration.
But it still seems like an interesting way to accomplish some kind of fault tolerance for any OS.
It'd be nice if they had fiber channel HBAs built into the blades. That would fix the IDE problem.
Is there an easy way to fix MP3 metadata?
on
80 Gig MP3 Player
·
· Score: 1
Like many people, I have a lot of MP3s downloaded off the net. I've noticed that 90% of them have either no ID3 tag at all, and of those that do have one its wrong, inaccurate, or has other problems that make it unusable.
Is there a way to fix this easily? At least make sure the artist and title are right?
The one thing I will grant to management is that "support" also can mean staff supportability. As someone who is tippy-toeing into the world of management, I have some great open source stuff running, but I only get enough salary money to hire/train people who have the deep skills it takes to understand and support stuff, specifically open source UNIX stuff.
It would be nice if commercially supported software meant it had perfect support. Too bad it doesn't, it often means big monolithic companies that admit that there's a problem but can't or won't fix it. I've personally had very disappointing and expensive support calls to vendors (not limited to MS) that can't support their product -- they just kind of shake their head and admit they don't know to fix it.
Taking the "supported" argument one further to third party support isn't much better, and is often worse since they want to charge you hundreds per hour to do time-consuming longshots that have little to do with FIXING the problem.
But the counterpoint is what do you do to fix problems with something you need when there is nothing behind it but your own ability to dig into the source? That's a practical option at a shop with a lot of talented systems programmers, but elsewhere it's a scary proposition.
My own version of "supported" is fuzzy and boils down to sticking with popular systems (somebody is likely maintaining the codebase), with simple configs (problems seem to enter more easily when you over-customize) and sticking to revs where most of the glitches have been found and fixed by somebody else.
I consider the ability to call support a last resort of dubious reliability.
This reminds me of a debate that my old boss and I had about stadium funding. His argument, which I think has some merit although I disagree with it, was that the government ought to subsidize the building of a new major league sports stadium. It may be a subsidy to the owners, but so is the millions of tax dollars that go into the highbrow arts (painting, sculpture, classical music, dance, theater, etc).
I disagreed with him for highbrow intellectual reasons -- the "arts" are the intellectual expression of our culture, and sports are not. As members of the culture, We have an obligation to support intellectual expressions of our culture.
Simply assigning a value to artistic expression on its commercial appeal or numerical appeal is a little myopic. You can't deny mass appeal, but using commerce and popularity as critical yardstick don't seem valid as measures because they don't address the content itself.
I'm only a dilettante when it comes to firearms, but the Kentucky Long Rifle, one of the first widely-produced rifled guns used roundball ammo and was legendary for being accurate to 200-400 yards.
Does rifling not help due to the low blast pressure? The flexibility of the ball?
Have they ever come out with clip-fed painball guns? Anything other than the gravity feed?
My guess is that any kind of spring-feed mechanism would be a lot of hassle with regular paintballs, since they'd be prone to breaking. The one time I played the gravity feed system let to lots of jamming and breakage.
What about rifled barrels? We used the low-budget range guns, but none had rifled barrels which made the guns accuracy proportional to how much CO2 you had in your gun. Even with the low-velocity rounds, a little spin might help..
I'd like to see a bus that was little more than a switch, with a minimum of logic for management.
For cards, it'd be great if each card had its own CPU and RAM. Ideally the cards would have a few universal connectors, each of which could accomodate an I/O module which would contain just the discrete electronics necessary to drive a specific device or medium (eg, video, audio, disk, network).
Bus-Switch modules would be interconnectable to accomodate more cards, and would have switch-like manegement features for segmentation, isolation and failover type features.
The CPU cards themselves ought to be less complicated than motherboards since there's no bus logic, just interconnect logic to the Switch-Bus and the I/O modules, and RAM.
Since each board has its own RAM and CPU it ought improve system performance because the O/S could offload much more processing to CPU boards dedicated to specific tasks. Instead of the kernal bothering with lower-level filesystem tasks and driving the hardware, a "driver" for filesystem and devices could be loaded on a CPU board dedicated to I/O.
The same could be true of user interfaces -- run the the UI on the board dedicated to video, audio and USB. The kernal could run applications or other jobs on the "processing" CPU board(s).
Networking? Offload the entire IP stack to the networking CPU board.
You do have to wonder what the limits of revenue growth are. It sometimes seems that the master plan for revenue growth is:
1) Eliminate competition.
2) Gain monopoly.
3) Make continued purchase of product a necessity for everyone.
4) Keep raising prices until all users pay a signficant portion of income to you (see #3 and #2).
At that point the limit to growth is population expansion, since you already have everyone paying you a percentage of everything you make. Which may lead to...
The trouble with Mickeysoft's DDNS is that they want to write records using prohibited character sets.
The other annoying thing (at least with BIND 8.x) is that enabling client updates kind of mangles nicely formatted zone files. This isn't MS's problem, and is probably overridable by $INCLUDE-ing the nice stuff and letting the primary zone file get mangled, er dynamically updated.
Just my thoughts. Sony sells all their portables with Memory Stick compatability; Apple sells for Mac compatability; Microsoft sells for Windows compatability.
It half makes sense, but many of Sony's products that are memory stick compatible are still usable even if you never own a memory stick as long as you live.
I wouldn't own a Macintosh (space+money mean the 5 PCs I own and use for business must stay), but I would own an iPod. But I can't because I'm not buying a $900 computer to own a $400 MP3 player.
Remember that there were those of us doing real work on Cisco and SunOS that paid the bills, including all the money that the web group squandered, back when internet meant the home office LAN and all the field offices linked together, not some dot-bomb fairyland.
I don't doubt that there are real pikers in many IT departments, but in the one I work in, there are very few. We were, however, subjected to a rotating collection of child "web designers" who knew fuckall outside of VB script and could have cared less about anything that they couldn't put into their Palm Pilots in under 30 seconds.
As for security, about half their sites (hosted externally) were owned in a week long period. Even after that they wondered why wouldn't let 'em run NT boxes open to the world.
Heh, I've seen (participated in?) the IT vs. Web development wars and it's not a good idea to have Web as a client of IT because IT is usually pissed/jealous/scared/disgusted at/of/at the Web group for many of the same reasons that the Web group can't stand IT.
.001 rev of some plugin or why we woudln't run machines with no security, hand out root passwords, etc.
I was on the IT side, and we had a shitpile of varied systems and thousands of end user computers to keep running *securely* and in whatever harmony the software would allow, within our budget, and within the complex politics that is most corporations. A complicated job by itself.
The web people I worked with were usually nice, I even respected some of them. But they didn't get the big picture of the total environment as well as we (tried to) do, and they were always at the bleeding edge of everything and were pissed because we wouldn't do massive client-side upgrades every time there was a
I'd agree with you that they need to be seperate, in fact I'd vote for totally seperate -- like in another building across town. I think better web sites (better interop, better functionality, etc) comes from not even dreaming about having any influence or control over the desktop environment.
But then, as others have pointed out, is the cost of the box, the manual. But those are just the manufacturing costs. You're leaving out entirely the management cost. Somebody at MS, presumably an entire department, has to supervise the manufacturing and distribution (itself another cost) of packaged software.
I'd guess that it costs MS at least $2M per year to have a small staff that supervises the production of XP boxed software. That's salary, benefits, office space, phones, coffee, scotch, hookers, hush money and everything else that it costs MS to have those people do the job of seeing that someone else makes CDs, prints manuals, shoves them into boxes and gets 'em trucked to the local Microcenter.
It's those numbers along with the manufacturing costs that gives MS their per-unit numbers.
despite the fact that sci-fi viewers are more intelligent than soap opera viewers
Heh, just because you think that soaps are stupid that doesn't mean that all soap viewers are stupid. It may be that soap viewers are very intelligent, but their intelligence is focused on relationships and emotions and psychological motivations rather than technology.
Personally I think that SciFi is most interesting when positing social questions (Philip K Dick, Ray Bradbury or even Heinlein) or when doing the aliens and gadget routine (Star Wars, etc). I think its weakest when it tries to focus on character development. I have yet to see characters in mainstream scifi get developed beyond the cardboard cutout stage. If I want good human interest (eg, people and social situations are the focus), I'll read someone who's a real fiction writer.
Complexity doesn't necessarily make a good narrative. Most of what are regarded as the best narritives are often very simple and easy to understand. Take Shakespeare for example -- there are very few storylines that don't have a direct parallel to a Shakespeare play, and his plays were written to amuse 16th century Londoners, a group probably much less educated than even today's soap opera viewers.
I think there's good reason for a SciFi TV show to focus on aliens, technology and action and shy away from overly involved narratives and excess character development. Most SciFi writers, when aiming for "deep" narratives make Paradise Lost look like an Archie comic and they're terrible at character development. I can't think of a single Voyager character that was either memorable or even interesting.
Speaking of Soaps, have you ever actually *tried* to watch one? I think they're unbelievably complicated. We tried in college to follow All My Children one quarter (on before lunch, no classes, etc) and found it inexplicable. Yet I've known people (mostly women) who can describe months of plotlines and intricate character motivations. Don't underestimate the soaps.
They probably do view it that way, but a lot of places would rather reap rewards with zero input, which has always been the bugaboo of open source development or any other "from each, to each" kind of economic model.
If every shop with more than 20 programmers donated 1 FTE of programming time to some centralized open source collective, I would imagine that the rewards might be magnitudes beyond what they gave. The question would be how would their time get assigned and who would manage it, both massive political questions.
I've had two recent bubble wrap experiences. Last march I shipped a DLT4000 drive wrapped in about 6" of bubble wrap from MN to CA. When I got to CA, the drive, an old Dec TZ-88 had its metal housing smashed so bad it was bent, and the metal housing on that drive has got to be .125" steel.
The odd thing was that the *box* was totally intact and showed no sign of being opened, crushed or otherwise mangled.
I'm totally at a loss as to what happened to it, it almost seems like it was internal inertia that mangled it because it doesn't seem possible for the damage that drive experienced to happen without the box looking like it had been delivered via howitzer.
I did the same thing again two weeks ago, but this time I wrapped the drive in 12" of bubble wrap (as in the drive plus wrap is now about 32", nearly round) and it survived OK.
I'd like to get some of that plastic and quick setting foam stuff that some things seem to ship with. It looks like you pretty much just spray foam in the box, lay a piece of plastic inside, lay your stuff down, and then lay plastic on top of it and then spray more foam -- totally contoured to match the item and the box.
If you're doing colo hundreds of miles away, it'd make sense to figure out how you want to do OOB management. We use HP servers and they have a great out of band management capability -- power off, on, restart and console-level keyboard and text mode display capabilities independant of the OS. Couple this with a modem and you should be able to handle anything short of a total reinstallation.
Dunno what your colo environment is, but if you're buying a couple of U of rack space you could add one of those serial port management gizmos that does dialup and telnet access to a few serial port for greater flexibility.
That being said, I've had good luck with FreeBSD just doing makeworld and installworld remotely and rebooting without the machine going foobar on me. My drive is like 10 miles and the longest part of the journey is from the parking garage to the machine room, but I haven't had to make it but once due to a stuck management controller (fixed by BIOS upgrade) that required "F2" to continue booting but also locked out out of band management.
The key is being able to whack the box remotely without driving in. Unless you totally screw the OS to the point of reinstallation, most systems with OOB capabilities can get you going when the OS prevents a ssh-type connection.
I've recently been quoted just over $2k per month for a multilink dual T1 connection. The sales engineer told me that beyond 6 T1s it was cheaper to go with fractional DS3. So I figure that $10k has to be buying a lot of bandwidth. I'd guess that it'd be something like 18Mbps, which is a lot of bandwidth.
Still, once you get into DS3 land the local loop has to be crushingly expensive.
It's a mixed bag, but the folks over at AFU claim that this is an old mapmaker's trick. Put nonexistant roads or other geographical features into the map so that if it gets duplicated you know its your map.
I've never found anything like this specifically, although I've gotten plenty lost before (specifically in Louisiana) when the map's idea of the road and the road's idea of the road differed.
I always presumed that this was something of an unintentional trap -- in order to make the map more quickly and easily, Big Name Map Company used a government provided map as a basis for their map and the government map was either wrong or woefully outdated. It usually hapens with county roads or other more rural throughfares.
Considering his racks, why not suggest the SmartUPS 3000RM? Just like the 3000 floor model, but it's rack mountable. The 3U version has a little less power than the 5U one, but they're a hell of a lot more space conscious in a racked environment.
Smarter yet would be getting a Trace power panel and some batteries and running the whole room's electrical system.
Uhhm, there is no such thing as "hardware journalling". It's an oxymoron. By definition, journalling is file system-dependent.
Why is that? A simple version of what I'm thinking of would be a disk controller with two disks attached. One is your real disk the other is the journal disk. Every block level operation would be written twice, once to the real disk, and one to the transaction log with a timestamp.
Clearly any reasonably busy filesystem would require a lot of storage to maintain the transaction log (and maybe that's what would make this impractical for high-volume systems), but how many systems with 100G of disk modify all 100G every day? 100G of disk with 10G of modification per day could be journaled for at least 9 days with an equivilent journal disk.
Speed is a non-issue, IMHO. Any reasonably modern disk array controller can handle mirrored writes with no problem, and this is not much different from mirroring.
Many SAN storage systems have the ability to make snapshot copies of individual LUNs, I was told by one vendor that they were working on the ability to make incremental copies of a snapshot.
Journaling a LUN seems like a logical extension of this ability, and a way to provide fault tolerance.
Are there any disk array controllers or other storage devices that do FS-independant journaling at the block level?
It'd be an interesting way of doing backups -- instead of restoring from tape, you could get the disk controller to back out changes to a specific timestamp.
I'm sure there are some gotchas -- without knowledge of the filesystem, a specific hardware level transaction may not have complete filesystem level coherency, for one. And it may take a lot of disk to keep a log of any decent duration.
But it still seems like an interesting way to accomplish some kind of fault tolerance for any OS.
It'd be nice if they had fiber channel HBAs built into the blades. That would fix the IDE problem.
Like many people, I have a lot of MP3s downloaded off the net. I've noticed that 90% of them have either no ID3 tag at all, and of those that do have one its wrong, inaccurate, or has other problems that make it unusable.
Is there a way to fix this easily? At least make sure the artist and title are right?
The one thing I will grant to management is that "support" also can mean staff supportability. As someone who is tippy-toeing into the world of management, I have some great open source stuff running, but I only get enough salary money to hire/train people who have the deep skills it takes to understand and support stuff, specifically open source UNIX stuff.
It would be nice if commercially supported software meant it had perfect support. Too bad it doesn't, it often means big monolithic companies that admit that there's a problem but can't or won't fix it. I've personally had very disappointing and expensive support calls to vendors (not limited to MS) that can't support their product -- they just kind of shake their head and admit they don't know to fix it.
Taking the "supported" argument one further to third party support isn't much better, and is often worse since they want to charge you hundreds per hour to do time-consuming longshots that have little to do with FIXING the problem.
But the counterpoint is what do you do to fix problems with something you need when there is nothing behind it but your own ability to dig into the source? That's a practical option at a shop with a lot of talented systems programmers, but elsewhere it's a scary proposition.
My own version of "supported" is fuzzy and boils down to sticking with popular systems (somebody is likely maintaining the codebase), with simple configs (problems seem to enter more easily when you over-customize) and sticking to revs where most of the glitches have been found and fixed by somebody else.
I consider the ability to call support a last resort of dubious reliability.
First lesson of economics: demand = value.
This reminds me of a debate that my old boss and I had about stadium funding. His argument, which I think has some merit although I disagree with it, was that the government ought to subsidize the building of a new major league sports stadium. It may be a subsidy to the owners, but so is the millions of tax dollars that go into the highbrow arts (painting, sculpture, classical music, dance, theater, etc).
I disagreed with him for highbrow intellectual reasons -- the "arts" are the intellectual expression of our culture, and sports are not. As members of the culture, We have an obligation to support intellectual expressions of our culture.
Simply assigning a value to artistic expression on its commercial appeal or numerical appeal is a little myopic. You can't deny mass appeal, but using commerce and popularity as critical yardstick don't seem valid as measures because they don't address the content itself.
Why wouldn't rifled barrels help?
I'm only a dilettante when it comes to firearms, but the Kentucky Long Rifle, one of the first widely-produced rifled guns used roundball ammo and was legendary for being accurate to 200-400 yards.
Does rifling not help due to the low blast pressure? The flexibility of the ball?
Have they ever come out with clip-fed painball guns? Anything other than the gravity feed?
My guess is that any kind of spring-feed mechanism would be a lot of hassle with regular paintballs, since they'd be prone to breaking. The one time I played the gravity feed system let to lots of jamming and breakage.
What about rifled barrels? We used the low-budget range guns, but none had rifled barrels which made the guns accuracy proportional to how much CO2 you had in your gun. Even with the low-velocity rounds, a little spin might help..
I'd like to see a bus that was little more than a switch, with a minimum of logic for management.
For cards, it'd be great if each card had its own CPU and RAM. Ideally the cards would have a few universal connectors, each of which could accomodate an I/O module which would contain just the discrete electronics necessary to drive a specific device or medium (eg, video, audio, disk, network).
Bus-Switch modules would be interconnectable to accomodate more cards, and would have switch-like manegement features for segmentation, isolation and failover type features.
The CPU cards themselves ought to be less complicated than motherboards since there's no bus logic, just interconnect logic to the Switch-Bus and the I/O modules, and RAM.
Since each board has its own RAM and CPU it ought improve system performance because the O/S could offload much more processing to CPU boards dedicated to specific tasks. Instead of the kernal bothering with lower-level filesystem tasks and driving the hardware, a "driver" for filesystem and devices could be loaded on a CPU board dedicated to I/O.
The same could be true of user interfaces -- run the the UI on the board dedicated to video, audio and USB. The kernal could run applications or other jobs on the "processing" CPU board(s).
Networking? Offload the entire IP stack to the networking CPU board.
You do have to wonder what the limits of revenue growth are. It sometimes seems that the master plan for revenue growth is:
1) Eliminate competition.
2) Gain monopoly.
3) Make continued purchase of product a necessity for everyone.
4) Keep raising prices until all users pay a signficant portion of income to you (see #3 and #2).
At that point the limit to growth is population expansion, since you already have everyone paying you a percentage of everything you make. Which may lead to...
5) Require increased reproduction.
The trouble with Mickeysoft's DDNS is that they want to write records using prohibited character sets.
The other annoying thing (at least with BIND 8.x) is that enabling client updates kind of mangles nicely formatted zone files. This isn't MS's problem, and is probably overridable by $INCLUDE-ing the nice stuff and letting the primary zone file get mangled, er dynamically updated.
He alludes to some FreeBSD vs. Linux benchmarks at the end of the peice. Anyone got any links?
Just my thoughts. Sony sells all their portables with Memory Stick compatability; Apple sells for Mac compatability; Microsoft sells for Windows compatability.
It half makes sense, but many of Sony's products that are memory stick compatible are still usable even if you never own a memory stick as long as you live.
I wouldn't own a Macintosh (space+money mean the 5 PCs I own and use for business must stay), but I would own an iPod. But I can't because I'm not buying a $900 computer to own a $400 MP3 player.