The article only mentions music - what about software? Would Apple and Microsoft have to provide DRM-free versions of their operating systems?
DRM is an attribute of the media, not the player. Without DRM-encumbered media, the "DRM capabilities" of the player are completely irrelevant, as they are never used.
Legislate away any possibility of DRM in the player and the market will move fairly quickly to eliminate the additional costs and complexity involved in implementing it in the players.
Ummm, right.... Before the 64s came out, AMD had the Socket A, which was around for a very long time (Duron through Athlon XP). Before that was (Super) Socket 7. How many sockets did Intel go through in the same amount of time? Check out Wikipedia.
Sticking with "mainstream" CPU sockets/slots (ie: no mobile or server parts, since they're not really relevant) since the K6 and Pentium 2 (1997), we have:
AMD (6)
Super socket 7
Slot A
Socket A
Socket 754
Socket 939
Socket AM2
Not on today's OSes and architectures, but those aren't the only possibilities.
Fundamentally, any "architecture" that allows the end user to make decisions about what it can do, allows the end user to make bad decisions.
Operating systems that enforce per-program restrictions do have a terrible record of being hard to use, and eventually someone will tell downloaders "remove jumper J4 to disable mandatory access control so you can install our dancing cursors.
Exactly. Which means that even if the default configuration doesn't let something happen, if the end user has the power to force it do so, then the system can't be secure.
Unfortunately, security has an inverse relationship with both ease of use and flexibility.
I'm using a Linux (CentOS) box as a firewall for my Windows network. Can you give me an example of the vulnerabilities you mention? I'd like to know how much risk I'm taking.
Recently, I had to put an SP1 WinXP online to demonstrate that it's (still) insecure to do that. I was expecting that the blaster menace has somewhat dwindled since its outbreak, simply 'cause it's been a while since its outbreak.
Clearly, you didn't turn on the firewall. Why not ?
That might have been true about 10 years ago, but I don't see that today in the application market place.
Well, I don't know where you're working, but certainly where I am the web app still has a long, long way to go before it can take over the world.
Certainly there are applications like MS-Office that run poorly under Wine (due to invoking undocumented APIs).
Ah, the good old undocumented APIs urban legend.
And in the case of MS-Office, you also have a strong competitor like Open Office that does nearly the same thing.
Except for all the things it doesn't do as well, or the same way.
And application developers do take Linux seriously with even commercial ports to Linux for many applications.
Many ? "A few" maybe. Linux still has a lot of growing up to do before it gets a heavy commercial software presence.
Since Microsoft dates to the early 1970's, that is a pretty large condemnation. And I would agree.
This is ridiculous. Microsoft were founded in 1975 and didn't have anything close a market dominating influence until around 1990 when Windows 3.0 became a surprise success. Until about 1995, Microsoft's influence outside of the low-low-end PC market was basically zero. You might - just barely - be able to mount an argument that they've had the power to "suppress" OS development since then, but the from-scratch development of major OS projects like Linux (even if it's just another unix), NeXT and BeOS during that timeframe, not to mention the continued development - including major changes like a hardware architecture switch - of MacOS make it pretty clear they haven't. Throw Microsoft's own contribution - Windows NT - into the mix, consider all the "others" like mainframes, UNIX variants, Netware, etc and your argument becomes even sillier.
That is exactly the point I was trying to make that it is Microsoft that is preventing any sort of serious development in terms of creating something really new.
No, the reality is that the kind of revolutionary improvements you're thinking about just aren't there to be made - and haven't been for decades.
I guess "some time before Microsoft" would go back to the 1960's?
"Some time before Microsoft", in the context of them dominating the market, would take you to about the beginning of the '90s. In an absolute sense, it would be any time before 1975. I'd have to say pretty much all the major issues of - and advances in - OS design theory were hashed out before 1975 ? Heck, even the first GUI concepts were banging around in research facilities before then - and while recent _implementation_ updates like Quartz, Aero and Compiz are non-trivial improvements, the basic premise is still the same as it was three decades ago.
Sorry, but the idea that Microsoft have suppressed OS development for 30-odd years just doesn't carry any weight in the face of actual evidence. (Added to that, I bet you're hypocritical enough to argue out of the other side of your mouth that Microsoft do nothing but copy other products.)
I have read your entire post and I still think you're totally full of it. The registry is a rotten idea, and flat files are a much better approach. I've already gone into my reasons for thinking so and I won't rehash them here.
That might be what you think, but you seem to be having a great deal of trouble coming up with reasons _why_, other than the ubiquitous "if the shit hits the fan it's easier to recover" line.
You are way too bitter and on edge about this conversation. I think you need a vacation. Someplace quiet, with no computers around, maybe a beach. Seriously. Whatever it is you do in your admin job, you don't seem to enjoy it!
Do not mistake a topic I have strong opinions on, combined with some Slashdot exaggeration, for "bitterness". I love my job (well, most of the time) and have a great working environment, with hours flexible enough that I can (and do, regularly) take 3 - 4 day weekends after only a casual "I'll be gone for a few days" to my boss. In about 6 months when I move to Switzerland to work from our Zurich office for a couple of years, I'm really looking forward to getting up in the morning ~3 days a week and choose between skiing and the office.
Trust, me, I'm a long, long way from high strung. I think my best man put it best - "if you were any more laid-back, you'd shit yourself".
And my software has been running without a hitch, updating tens of thousands of rows at a time, without error for a long time now. It's easy to configure, easy to work with, and many VERY talented people have complimented me on it. It doesn't touch the registry, it uses flat files and XML.
I wonder how much of the functionality provided by the Registry you have reinvented to work with your XML flat files ? How do you avoid the problems inherent to text files that the Registry solves, as outlined in my original post ? Or do you just ignore them ?
Most people's complaints about the Registry are based on experience gained with Windows *95* and its less-than-ideal implementation, and hasn't been updated since. Does that describe you ?
Anyway, what are you still doing here! Go chill out for a while! The beach is calling you.
Good idea. While Sydney is far from the nicest place to live, it does at least have some nice beaches.
You weren't really paying attention there were you? Point 2 for example. My whole point is that the documented API is not working the way that you expected. Bad docs? Bad code? Who cares, it's not working. Your approach apparently is to throw your hands in the air, and go and sulk in the corner. Someone that can reverse engineer the driver will be able to continue going forward.
Sure, with some bad code that will likely break every time the other vendor changes anything.
It's crap like this that causes 90% of the problems on Windows. Developers write their code to some "reverse engineered" spec of the API, rather than the documented one, so then when the API's implementation changes in some minor way, all those badly written applications brreak. Microsoft subsequently has to write in layer after layer of "bug compatibility" so old applications don't break.
Anyone that wants to be a good programmer needs to know about the underlying architecture. At least, that's Jeremy Allison's position, which I happen to share. But apparently you think you know more about what a good programmer needs to know than Jeremy
No, I said I can see why people trying to write high performance network servers and other such performance sensitive code - clearly the type of developers Mr Allison's remarks are most relevant to - will benefit from knowing the underlying architecture.
However, that's not the majority of code out there being written. For most developers, knowing the architecture is handy, but far, far from essential.
Well, I guess the arms manufacturers are obviously more evil then Microsoft. And arguably the oil companies and the drug companies.
Car manufacturers (remember the recall equation ?), tobacco companies, clothing manufacturers using sweatshops, lots of of mining companies with operations in the third world, a large chunk of the "adult entertainment" industry...
Heck, that's without even taking more than thirty seconds to think about it.
But really, you Microsoft defenders are a joke. I guess you all work for Microsoft, or are stockholders or otherwise benefit from them.
I'm not defending anyone. I'm pointing out that if you consider Microsoft to be "evil", you've either incredibly naive or you've got a pretty fucked up sense of morality.
About the most "evil" thing Microsoft could be accused of doing is putting somebody out of business. Compared to knowingly ignoring product flaws that kill customers, selling a product that kills customers (and misleading them about it while deliberately making it more addictive), keeping workers in slavelike conditions, etc, etc, it should struggle to even register a "so what" on most normal people's outrage meters.
IMHO Microsoft could easily redeem themselves by simply releasing scaled down versions of vista that will run on older hardware.
What possible reason could there be for doing this ? A new <US$500 PC will run Vista fine and anyone too cheap to spend a piddling amount upgrading "older" PCs isn't going to pay for Vista.
The software giant could create a huge market overnight if they just quickly took advantage of the huge existing number of desktop work stations that have p111s and older p4s with 256 meg of ram. After all the Aero desktop is not a priority for someone running Quicken.
Can you explain why you think someone who won't pay ~$50 to ~$100 to upgrade an existing computer to 768MB - 1GB RAM will pay ~$200 - ~$300 for Vista ?
It is telling that a scaled down version of Vista is already available to customers in countries other than the so called first world.
It's only "scaled down" in that it doesn't do as much, not in that it will run on less hardware.
My point? Microsoft due to its monopoly has asphyxiated nearly all operating system development. Sure, there are some interesting things happening with Linux, but even that is largely a rough copy under a different paradigm.
Hardly. The problem is people want to run applications. End-user applications are, by and large, constrained to a single platform. *That* is why Windows dominates because it runs the applications.
Apple does some cool stuff too, but their operating system has almost never been their best feature, nor their main focus. They are a computer equipment company that happens to sell some cool alternative operating systems. And look where Apple is successful: the iPod. The computer equipment business is still profitable, and as long as it is they will continue to make that kind of stuff. But I wouldn't rely upon Apple to come up with the next cool OS platform either.
Say what ? MacOS has been basically the only reason anyone would buy a Mac. Without MacOS, a Mac is just an expensive PC. While the iPod has certainly taken over as Apple's main claim to fame, to say their OS has "never been their best feature" doesn't even pass the laught test. Until a few years ago it was basically their *only* feature.
If Microsoft dies, I will be suggesting a strong "R.I.P." epitaph for the company, but I also don't think anybody will come up with any other new operating system concepts until then. Why? Microsoft. They will take nearly everything in this area and either duplicate it or kill it with no mercy. Even in their death, Microsoft can still pack a powerful punch, and any really innovative ideas that might be commercially viable will only give Microsoft a breath of fresh air to pick up the torch again.
Quite arguably, there hadn't been any "new operating system concepts" for some time before Microsoft even existed. You'd struggle to find much that's been revolutionary in the field of operating system design for several decades.
You can't be one of the most hated companies in the world without some negative effects.
Anyone who has Microsoft on (or even close to) the top of their "companies I hate" list is leading a very sheltered and naive life - they need to get out of their mother's basement and acquire some perspective.
On the scale of "corporate evilness", Microsoft wouldn't even get past the hump in the middle.
That is probably how it should read. MS didnt write anything they currently sell. They acquired it and revised it and added stuff to it. There is a very very long list of all of MS' acquisitions someplace online listing them all - including every part of Office, the entire graphics engine (including DirectX), IE, the Windows GUI, The WinXP theme changes, DOS, Win16, IIS, Exchange, and on and on. Acquired and added to by MS.
Price points for these are $599 (1.6Ghz Core Duo Combo Drive), $799 (1.8Ghz Core Duo SuperDrive), and... yea, OK, there seems to be a gap here ( what's wrong w/ the iMac screen, again? )... the 2.0GHz Mac Pro at $2,200.
The first problem is that it's there. Big turn off for anyone that already has a good screen, or likes to buy new machines frequently.
The second problem is the video card driving it is both a) average and b) fixed.
I guess they figure you would want to use the iMac screen? How would a model without a screen boost sales in the midrange? What do you need that a Mac Mini is somehow unfit for, but wouldn't benefit from dual 2.0Ghz Xeons?
A better question is how many people for whom a Mac Mini is insufficient, could happily get by with a machine that was "half" a Mac Pro (which is to say, a single x16-slotted PCIe video card, a single free x4 PCIe slot, single GB ethernet, one dual-core (quad-core option) CPU and two hard disks) ?
The answer is "lots" (I'd venture "most", for that part of the market after standalone machines), and is the reason why Apple won't do it - such a machine would slaughter the higher margin Mac Pro sales (although sales in the midrange would go through the roof).
The lack of a mid-range standalone deskop is a gaping hole in Apple's lineup and has been for ages. It's a long, long jump from a lowly Mac Mini to a stomping quad-core Mac Pro, both in terms of capabilities and price.
So not true. A simple example. You're writing a video editting program that needs access to the graphics card. Sadly your code and the card's driver aren't playing nice together. You've read the docs, you think you're doing the right thing, no-one on the forums can give you any pointers. What do you do? Ideally, you'd have a look at the source code of the driver - the ultimate documentation, to see what the driver is expecting of you. Trouble is, you're coding against an NVidia graphics card, and the bastards don't give out the source code.
1. Video editing. That's performance-sensitive code, so you don't even get off the mark ok.
2. You shouldn't be talking to the hardware, you should be talking to the system API.
3. You should be writing to the documented API, not delving inside the source code and reverse-engineering how you think it works. Doing so is very, very bad practice and will likely result in fragile code tied to a specific implementation of the API (shennanigans like this are the primary reason software updates in Windows sometimes break applications).
This is not some pie-in-the-sky, never happens kind of scenario. I work in an embedded environment.
Well, duh. At no point did I say there was no reason for any developers to know about the hardware. Why are you trying to pretend I did ?
The only other option is black-box testing to identify what the client is doing wrong, and even then you can only tell them in general terms.
No, the other - proper - option is to tell them their API isn't acting the way their documentation says it does. Not to fix their problem. Not to write your code to work around their problem (so that it breaks when they subsequently fix it).
There is no coding job in the world where an understanding of the underlying architecture won't enable you to be more effective.
Something I haven't disagreed with. It is, however, far from _necessary_ for a non-trivial amount of coding work out there. Someone writing a low-usage web app doesn't need to know assembler.
That's all they do. I don't know where you're inventing these disclaimers out of thin air, but they simply don't exist. They obviously aren't in the stickers, and they aren't in the ads.
They're quite clearly printed on Microsoft's and Dell's (to pick one high profile reseller) web sites.
Now, I'm sure Vista comes with a disclaimer, but the lawsuit isn't about people buying Vista in stores. It's about people who bought computers because they were informed that Vista (Something either came with the computer or that they were considering purchasing later.) could do certain things, and that the computer could support Vista.
Then they should be attempting to the sue the computer seller. On the (very) slim chance the seller didn't have fine print detailing the different system requirements, they might even have a case.
Whether they actually ended up with a copy of Vista is irrelevant, they're asserting the computers were sold under false pretenses thanks to MS ads. And, considering that MS is the one who labeled the computers and ran the ads, MS is the ones they are suing.
Microsoft quite clearly state the system requirements for Vista. They are unuestionably blameless if either a) customers don't read those system requirements or b) a hardware reseller defrauds a customer.
I agree completely since it is a fact that has been established over the years, [...]
I have to argue there are still a lot of computing applications where the network is of only tangential interest. Word processing, desktop publishing, video editing, [single player] games, etc. There's no shortage of work where the network is really just a a process for getting an initial set of data onto the machine to be manipulated (if it even does that - eg: photo editing with photos coming straight off the camera).
Mr Allison's advice (and commentary) seems to be very much centred around writing high-performance server applications. Which is hardly surprising, given his background, but may not be equally applicable to all forms of coding (eg: writing GUI apps for GNOME or KDE today is probably quite different to writing X apps twenty+ years ago, and an intimate knowledge of the underlying hardware/OS is only really necessary if your code is performance-sensitive).
[...] i still wonder if iTunes(one of the best examples i could remember) would have been so widely used today if not for the music sharing feature!
Of course it would. The iPod is the main reason iTunes is popular (( don't think I've _ever_ used iTunes music sharing features - or the iTunes Store, for that matter).
On the other hand, the best way to make a lot of money has, up to now, been to know the right proprietary software. There was a time, not so long ago, when knowing Oracle would make the difference between making $30k or making $100k. I have a relative who made a lot of money because he was an expert in MUMPS. I think that is changing. Open source is the future.
Open Source will not change this. Despite what seems to be common belief among some people, a program being open source does not make it a commodity. Non-trivial environments do not change software platforms on a whim, be they proprietry or open source.
What really stands out in your post is that you have an adversarial relationship with your users.
Years of being a sysadmin does that to you. It's called "harsh reality".
The difference here is that I _know_ end users will abuse their tools and because of that I take pro-active steps to either remove their ability to do so, or reduce the potential impact. You hope they won't and use that as an excuse to be lazy and blame them for your mistakes.
Yeah, so what?
"What" is that your job is to make your software well enough so that they *can't* break it.
You don't hang around with Open-Source types much, do you?See, if they want to break the software, hell, let them have fun. Because the config file is just a flat file, they can put it right back the way it was at any time, so there's no risk.
If your software breaks because someone puts the wrong line in a configuration file, it sucks, is broken and you should be ashamed to have designed it so badly. Doubly so if it was already working before the change was made.
Try THAT with your registry.
Trivial. Export the key. Delete and reimport if necessary. Of course, software that requires messing around directly with the Registry as SOP in the first place has already failed.
Backing up (and restoring if necessary) your program's configuration data is not my responsibility. It is *your* responsibility, as part of your overall aim to make reliable, user friendly software. Software that stops working because I mistype a configuration variable or set it to the wrong thing, is neither user friendly, nor reliable. Software that requires me to even be in that position in the first place, is badly designed.
Here's something else your registry can't do. Some customer tinkers with his config file. He breaks the software. He calls me up. "Hey, I broke the config file or something", he says. I say "Ok, put your cd in and copy this file to your install directory". Wow, it's working again.
Of course it can. Although, if the developer had done their job properly *in the first place*, the end user wouldn't be able to make modifications to a configuration file that broke their software - or, at worst, the software would recognise the bad data and ignore it so the user could either keep working, or reset to sane defaults.
But you whip-crackin' kids just hate that boring old design part, don't you ? Much more interesting to just get in there and shit out some code. After all, you can always rewrite it again later a few times until you finally get it right. Never mind the cost of people's time that you waste in the process.
Flat files are neat, aren't they?
Not nearly as neat as properly designed software.
The model of having end users (and that includes everyone from the novice to the seasoned expert) manually editing text files to configure systems *as a matter of course* is stupid, broken and fundamentally unreliable. Heck, it's barely tolerable for trying to solve corner-case, special-needs problems.
Oh, my oh me. You know nothing about me OR my software.
Sure I do. You've been telling me all about the bad habits you have, how you prefer to fix problems reactively rather than proactively and how tied you are to a particular mindset.
Sorry. I forgot how humorless you were. Never mind (harrrumph). It's probably all that Microsoft dreck that's got you so grouchy. Hey, buy me a case of corona and I'll set up Slackware for you. It'll take only a couple of hours, but it'll make you SO much happier! I'm pretty sure your face won't crack if you grin, but we'll take it slow just in case.
Thanks, but my fleet of Linux servers are running quite well on their own, despite people like you trying to make that difficult.
The way you would allow the user to copy software from machine to machine despite the presence of a registry would be to NOT USE THE REGISTRY FOR THAT SOFTWARE. Meaning,
Look, all your objections to using flat files are straw man arguments.
No, they're not. The *only* redeeming feature "flat files" have is that they're "easier" (*very* much a relative term) to manually recover by hand in the case of disaster.
If I'm building an application and I want to set up a config file, it's trivially easy to set up an XML file, read it in and parse it.
Or you could just make a couple of API calls to the atomic, secure, system DB that someone else has already been nice enough to provide for you.
If I'm a halfway decent programmer, I'll be done in half an hour and it'll be perfect.
If by "perfect" you mean subject to all the problems I've already listed, plus be vulnerable to bugs in your reinventions of various wheels, then yes, it will be "perfect".
What makes it much better than your registry is that my USERS can edit the file themselves, because I TRUST THEM.
Then you're a fool. End users will, at every turn, try to break your software, either deliberately or accidentally. Bad input is the primary weapon they will utilise in these efforts.
See, I'm from New York, not Redmond. A user who just gave me money for something is my brand-new Best Friend. He can do whatever the hell he wants with my project; hell, he can print out the code and roll around naked in it for all I care.
Right. Because that way it's easier to just blame the end user for your badly written software.
The POINT is, using a registry makes you a pain in the ass. Your user can't just copy your install directory to his new computer. He has to go through your buggy installer. He loses all his settings. And so on.
Of course he can, assuming you, the developer, allow him to.
Using flat files means I'm NOT a pain in the ass. If one of MY users wants to copy my software to a new machine, he can just copy the directory and the config file over. Piece of cake, really.
Slashdot Mirror
Does this mean that software bought to run on a Windows PC should also run on a Mac, Linux PC, whatever?
No, it means it should not be artificially restricted from doing so.
This is a completely separate issue from _requiring_ software to be multiplatform.
The article only mentions music - what about software? Would Apple and Microsoft have to provide DRM-free versions of their operating systems?
DRM is an attribute of the media, not the player. Without DRM-encumbered media, the "DRM capabilities" of the player are completely irrelevant, as they are never used.
Legislate away any possibility of DRM in the player and the market will move fairly quickly to eliminate the additional costs and complexity involved in implementing it in the players.
OK. Maybe I'm just behind the times or something, but what was "wrong" with GPLv2?
It's still too easy to "productise" GPLed code (eg: by tying it to a hardware device like Tivo did).
He was claiming Linux is too vulnerable to use as an internet facing box. My Linux firewall is connected to the internet. Is it vulnerable?
Depends what you're letting through the firewall. Which is the point - if there's a firewall blocking the traffic, OS vulnerabilities are mostly moot.
Ummm, right.... Before the 64s came out, AMD had the Socket A, which was around for a very long time (Duron through Athlon XP). Before that was (Super) Socket 7. How many sockets did Intel go through in the same amount of time? Check out Wikipedia.
Sticking with "mainstream" CPU sockets/slots (ie: no mobile or server parts, since they're not really relevant) since the K6 and Pentium 2 (1997), we have:
AMD (6)
Super socket 7
Slot A
Socket A
Socket 754
Socket 939
Socket AM2
Intel (5)
Slot 1
Socket 370
Socket 423
Socket 478
LGA 775
Seems pretty even to me...
Not on today's OSes and architectures, but those aren't the only possibilities.
Fundamentally, any "architecture" that allows the end user to make decisions about what it can do, allows the end user to make bad decisions.
Operating systems that enforce per-program restrictions do have a terrible record of being hard to use, and eventually someone will tell downloaders "remove jumper J4 to disable mandatory access control so you can install our dancing cursors.
Exactly. Which means that even if the default configuration doesn't let something happen, if the end user has the power to force it do so, then the system can't be secure.
Unfortunately, security has an inverse relationship with both ease of use and flexibility.
I'm using a Linux (CentOS) box as a firewall for my Windows network. Can you give me an example of the vulnerabilities you mention? I'd like to know how much risk I'm taking.
I think you kind of missed his point...
Recently, I had to put an SP1 WinXP online to demonstrate that it's (still) insecure to do that. I was expecting that the blaster menace has somewhat dwindled since its outbreak, simply 'cause it's been a while since its outbreak.
Clearly, you didn't turn on the firewall. Why not ?
That might have been true about 10 years ago, but I don't see that today in the application market place.
Well, I don't know where you're working, but certainly where I am the web app still has a long, long way to go before it can take over the world.
Certainly there are applications like MS-Office that run poorly under Wine (due to invoking undocumented APIs).
Ah, the good old undocumented APIs urban legend.
And in the case of MS-Office, you also have a strong competitor like Open Office that does nearly the same thing.
Except for all the things it doesn't do as well, or the same way.
And application developers do take Linux seriously with even commercial ports to Linux for many applications.
Many ? "A few" maybe. Linux still has a lot of growing up to do before it gets a heavy commercial software presence.
Since Microsoft dates to the early 1970's, that is a pretty large condemnation. And I would agree.
This is ridiculous. Microsoft were founded in 1975 and didn't have anything close a market dominating influence until around 1990 when Windows 3.0 became a surprise success. Until about 1995, Microsoft's influence outside of the low-low-end PC market was basically zero. You might - just barely - be able to mount an argument that they've had the power to "suppress" OS development since then, but the from-scratch development of major OS projects like Linux (even if it's just another unix), NeXT and BeOS during that timeframe, not to mention the continued development - including major changes like a hardware architecture switch - of MacOS make it pretty clear they haven't. Throw Microsoft's own contribution - Windows NT - into the mix, consider all the "others" like mainframes, UNIX variants, Netware, etc and your argument becomes even sillier.
That is exactly the point I was trying to make that it is Microsoft that is preventing any sort of serious development in terms of creating something really new.
No, the reality is that the kind of revolutionary improvements you're thinking about just aren't there to be made - and haven't been for decades.
I guess "some time before Microsoft" would go back to the 1960's?
"Some time before Microsoft", in the context of them dominating the market, would take you to about the beginning of the '90s. In an absolute sense, it would be any time before 1975. I'd have to say pretty much all the major issues of - and advances in - OS design theory were hashed out before 1975 ? Heck, even the first GUI concepts were banging around in research facilities before then - and while recent _implementation_ updates like Quartz, Aero and Compiz are non-trivial improvements, the basic premise is still the same as it was three decades ago.
Sorry, but the idea that Microsoft have suppressed OS development for 30-odd years just doesn't carry any weight in the face of actual evidence. (Added to that, I bet you're hypocritical enough to argue out of the other side of your mouth that Microsoft do nothing but copy other products.)
I have read your entire post and I still think you're totally full of it. The registry is a rotten idea, and flat files are a much better approach. I've already gone into my reasons for thinking so and I won't rehash them here.
That might be what you think, but you seem to be having a great deal of trouble coming up with reasons _why_, other than the ubiquitous "if the shit hits the fan it's easier to recover" line.
You are way too bitter and on edge about this conversation. I think you need a vacation. Someplace quiet, with no computers around, maybe a beach. Seriously. Whatever it is you do in your admin job, you don't seem to enjoy it!
Do not mistake a topic I have strong opinions on, combined with some Slashdot exaggeration, for "bitterness". I love my job (well, most of the time) and have a great working environment, with hours flexible enough that I can (and do, regularly) take 3 - 4 day weekends after only a casual "I'll be gone for a few days" to my boss. In about 6 months when I move to Switzerland to work from our Zurich office for a couple of years, I'm really looking forward to getting up in the morning ~3 days a week and choose between skiing and the office.
Trust, me, I'm a long, long way from high strung. I think my best man put it best - "if you were any more laid-back, you'd shit yourself".
And my software has been running without a hitch, updating tens of thousands of rows at a time, without error for a long time now. It's easy to configure, easy to work with, and many VERY talented people have complimented me on it. It doesn't touch the registry, it uses flat files and XML.
I wonder how much of the functionality provided by the Registry you have reinvented to work with your XML flat files ? How do you avoid the problems inherent to text files that the Registry solves, as outlined in my original post ? Or do you just ignore them ?
Most people's complaints about the Registry are based on experience gained with Windows *95* and its less-than-ideal implementation, and hasn't been updated since. Does that describe you ?
Anyway, what are you still doing here! Go chill out for a while! The beach is calling you.
Good idea. While Sydney is far from the nicest place to live, it does at least have some nice beaches.
You weren't really paying attention there were you? Point 2 for example. My whole point is that the documented API is not working the way that you expected. Bad docs? Bad code? Who cares, it's not working. Your approach apparently is to throw your hands in the air, and go and sulk in the corner. Someone that can reverse engineer the driver will be able to continue going forward.
Sure, with some bad code that will likely break every time the other vendor changes anything.
It's crap like this that causes 90% of the problems on Windows. Developers write their code to some "reverse engineered" spec of the API, rather than the documented one, so then when the API's implementation changes in some minor way, all those badly written applications brreak. Microsoft subsequently has to write in layer after layer of "bug compatibility" so old applications don't break.
Anyone that wants to be a good programmer needs to know about the underlying architecture. At least, that's Jeremy Allison's position, which I happen to share. But apparently you think you know more about what a good programmer needs to know than Jeremy
No, I said I can see why people trying to write high performance network servers and other such performance sensitive code - clearly the type of developers Mr Allison's remarks are most relevant to - will benefit from knowing the underlying architecture.
However, that's not the majority of code out there being written. For most developers, knowing the architecture is handy, but far, far from essential.
Well, I guess the arms manufacturers are obviously more evil then Microsoft. And arguably the oil companies and the drug companies.
Car manufacturers (remember the recall equation ?), tobacco companies, clothing manufacturers using sweatshops, lots of of mining companies with operations in the third world, a large chunk of the "adult entertainment" industry...
Heck, that's without even taking more than thirty seconds to think about it.
But really, you Microsoft defenders are a joke. I guess you all work for Microsoft, or are stockholders or otherwise benefit from them.
I'm not defending anyone. I'm pointing out that if you consider Microsoft to be "evil", you've either incredibly naive or you've got a pretty fucked up sense of morality.
About the most "evil" thing Microsoft could be accused of doing is putting somebody out of business. Compared to knowingly ignoring product flaws that kill customers, selling a product that kills customers (and misleading them about it while deliberately making it more addictive), keeping workers in slavelike conditions, etc, etc, it should struggle to even register a "so what" on most normal people's outrage meters.
IMHO Microsoft could easily redeem themselves by simply releasing scaled down versions of vista that will run on older hardware.
What possible reason could there be for doing this ? A new <US$500 PC will run Vista fine and anyone too cheap to spend a piddling amount upgrading "older" PCs isn't going to pay for Vista.
The software giant could create a huge market overnight if they just quickly took advantage of the huge existing number of desktop work stations that have p111s and older p4s with 256 meg of ram. After all the Aero desktop is not a priority for someone running Quicken.
Can you explain why you think someone who won't pay ~$50 to ~$100 to upgrade an existing computer to 768MB - 1GB RAM will pay ~$200 - ~$300 for Vista ?
It is telling that a scaled down version of Vista is already available to customers in countries other than the so called first world.
It's only "scaled down" in that it doesn't do as much, not in that it will run on less hardware.
My point? Microsoft due to its monopoly has asphyxiated nearly all operating system development. Sure, there are some interesting things happening with Linux, but even that is largely a rough copy under a different paradigm.
Hardly. The problem is people want to run applications. End-user applications are, by and large, constrained to a single platform. *That* is why Windows dominates because it runs the applications.
Apple does some cool stuff too, but their operating system has almost never been their best feature, nor their main focus. They are a computer equipment company that happens to sell some cool alternative operating systems. And look where Apple is successful: the iPod. The computer equipment business is still profitable, and as long as it is they will continue to make that kind of stuff. But I wouldn't rely upon Apple to come up with the next cool OS platform either.
Say what ? MacOS has been basically the only reason anyone would buy a Mac. Without MacOS, a Mac is just an expensive PC. While the iPod has certainly taken over as Apple's main claim to fame, to say their OS has "never been their best feature" doesn't even pass the laught test. Until a few years ago it was basically their *only* feature.
If Microsoft dies, I will be suggesting a strong "R.I.P." epitaph for the company, but I also don't think anybody will come up with any other new operating system concepts until then. Why? Microsoft. They will take nearly everything in this area and either duplicate it or kill it with no mercy. Even in their death, Microsoft can still pack a powerful punch, and any really innovative ideas that might be commercially viable will only give Microsoft a breath of fresh air to pick up the torch again.
Quite arguably, there hadn't been any "new operating system concepts" for some time before Microsoft even existed. You'd struggle to find much that's been revolutionary in the field of operating system design for several decades.
You can't be one of the most hated companies in the world without some negative effects.
Anyone who has Microsoft on (or even close to) the top of their "companies I hate" list is leading a very sheltered and naive life - they need to get out of their mother's basement and acquire some perspective.
On the scale of "corporate evilness", Microsoft wouldn't even get past the hump in the middle.
That is probably how it should read. MS didnt write anything they currently sell. They acquired it and revised it and added stuff to it. There is a very very long list of all of MS' acquisitions someplace online listing them all - including every part of Office, the entire graphics engine (including DirectX), IE, the Windows GUI, The WinXP theme changes, DOS, Win16, IIS, Exchange, and on and on. Acquired and added to by MS.
Everyone does this... What's your point ?
I've worked with VMS a lot, and Windows NT is not VMS!
DEC disagreed. Indeed, they even went to court about it.
Only as long as you choose to.
Price points for these are $599 (1.6Ghz Core Duo Combo Drive), $799 (1.8Ghz Core Duo SuperDrive), and ... yea, OK, there seems to be a gap here ( what's wrong w/ the iMac screen, again? )... the 2.0GHz Mac Pro at $2,200.
The first problem is that it's there. Big turn off for anyone that already has a good screen, or likes to buy new machines frequently.
The second problem is the video card driving it is both a) average and b) fixed.
I guess they figure you would want to use the iMac screen? How would a model without a screen boost sales in the midrange? What do you need that a Mac Mini is somehow unfit for, but wouldn't benefit from dual 2.0Ghz Xeons?
A better question is how many people for whom a Mac Mini is insufficient, could happily get by with a machine that was "half" a Mac Pro (which is to say, a single x16-slotted PCIe video card, a single free x4 PCIe slot, single GB ethernet, one dual-core (quad-core option) CPU and two hard disks) ?
The answer is "lots" (I'd venture "most", for that part of the market after standalone machines), and is the reason why Apple won't do it - such a machine would slaughter the higher margin Mac Pro sales (although sales in the midrange would go through the roof).
The lack of a mid-range standalone deskop is a gaping hole in Apple's lineup and has been for ages. It's a long, long jump from a lowly Mac Mini to a stomping quad-core Mac Pro, both in terms of capabilities and price.
So not true. A simple example. You're writing a video editting program that needs access to the graphics card. Sadly your code and the card's driver aren't playing nice together. You've read the docs, you think you're doing the right thing, no-one on the forums can give you any pointers. What do you do? Ideally, you'd have a look at the source code of the driver - the ultimate documentation, to see what the driver is expecting of you. Trouble is, you're coding against an NVidia graphics card, and the bastards don't give out the source code.
1. Video editing. That's performance-sensitive code, so you don't even get off the mark ok.
2. You shouldn't be talking to the hardware, you should be talking to the system API.
3. You should be writing to the documented API, not delving inside the source code and reverse-engineering how you think it works. Doing so is very, very bad practice and will likely result in fragile code tied to a specific implementation of the API (shennanigans like this are the primary reason software updates in Windows sometimes break applications).
This is not some pie-in-the-sky, never happens kind of scenario. I work in an embedded environment.
Well, duh. At no point did I say there was no reason for any developers to know about the hardware. Why are you trying to pretend I did ?
The only other option is black-box testing to identify what the client is doing wrong, and even then you can only tell them in general terms.
No, the other - proper - option is to tell them their API isn't acting the way their documentation says it does. Not to fix their problem. Not to write your code to work around their problem (so that it breaks when they subsequently fix it).
There is no coding job in the world where an understanding of the underlying architecture won't enable you to be more effective.
Something I haven't disagreed with. It is, however, far from _necessary_ for a non-trivial amount of coding work out there. Someone writing a low-usage web app doesn't need to know assembler.
That's all they do. I don't know where you're inventing these disclaimers out of thin air, but they simply don't exist. They obviously aren't in the stickers, and they aren't in the ads.
They're quite clearly printed on Microsoft's and Dell's (to pick one high profile reseller) web sites.
Now, I'm sure Vista comes with a disclaimer, but the lawsuit isn't about people buying Vista in stores. It's about people who bought computers because they were informed that Vista (Something either came with the computer or that they were considering purchasing later.) could do certain things, and that the computer could support Vista.
Then they should be attempting to the sue the computer seller. On the (very) slim chance the seller didn't have fine print detailing the different system requirements, they might even have a case.
Whether they actually ended up with a copy of Vista is irrelevant, they're asserting the computers were sold under false pretenses thanks to MS ads. And, considering that MS is the one who labeled the computers and ran the ads, MS is the ones they are suing.
Microsoft quite clearly state the system requirements for Vista. They are unuestionably blameless if either a) customers don't read those system requirements or b) a hardware reseller defrauds a customer.
I agree completely since it is a fact that has been established over the years, [...]
I have to argue there are still a lot of computing applications where the network is of only tangential interest. Word processing, desktop publishing, video editing, [single player] games, etc. There's no shortage of work where the network is really just a a process for getting an initial set of data onto the machine to be manipulated (if it even does that - eg: photo editing with photos coming straight off the camera).
Mr Allison's advice (and commentary) seems to be very much centred around writing high-performance server applications. Which is hardly surprising, given his background, but may not be equally applicable to all forms of coding (eg: writing GUI apps for GNOME or KDE today is probably quite different to writing X apps twenty+ years ago, and an intimate knowledge of the underlying hardware/OS is only really necessary if your code is performance-sensitive).
[...] i still wonder if iTunes(one of the best examples i could remember) would have been so widely used today if not for the music sharing feature!
Of course it would. The iPod is the main reason iTunes is popular (( don't think I've _ever_ used iTunes music sharing features - or the iTunes Store, for that matter).
On the other hand, the best way to make a lot of money has, up to now, been to know the right proprietary software. There was a time, not so long ago, when knowing Oracle would make the difference between making $30k or making $100k. I have a relative who made a lot of money because he was an expert in MUMPS. I think that is changing. Open source is the future.
Open Source will not change this. Despite what seems to be common belief among some people, a program being open source does not make it a commodity. Non-trivial environments do not change software platforms on a whim, be they proprietry or open source.
What really stands out in your post is that you have an adversarial relationship with your users.
Years of being a sysadmin does that to you. It's called "harsh reality".
The difference here is that I _know_ end users will abuse their tools and because of that I take pro-active steps to either remove their ability to do so, or reduce the potential impact. You hope they won't and use that as an excuse to be lazy and blame them for your mistakes.
Yeah, so what?
"What" is that your job is to make your software well enough so that they *can't* break it.
You don't hang around with Open-Source types much, do you?See, if they want to break the software, hell, let them have fun. Because the config file is just a flat file, they can put it right back the way it was at any time, so there's no risk.
If your software breaks because someone puts the wrong line in a configuration file, it sucks, is broken and you should be ashamed to have designed it so badly. Doubly so if it was already working before the change was made.
Try THAT with your registry.
Trivial. Export the key. Delete and reimport if necessary. Of course, software that requires messing around directly with the Registry as SOP in the first place has already failed.
Backing up (and restoring if necessary) your program's configuration data is not my responsibility. It is *your* responsibility, as part of your overall aim to make reliable, user friendly software. Software that stops working because I mistype a configuration variable or set it to the wrong thing, is neither user friendly, nor reliable. Software that requires me to even be in that position in the first place, is badly designed.
Here's something else your registry can't do. Some customer tinkers with his config file. He breaks the software. He calls me up. "Hey, I broke the config file or something", he says. I say "Ok, put your cd in and copy this file to your install directory". Wow, it's working again.
Of course it can. Although, if the developer had done their job properly *in the first place*, the end user wouldn't be able to make modifications to a configuration file that broke their software - or, at worst, the software would recognise the bad data and ignore it so the user could either keep working, or reset to sane defaults.
But you whip-crackin' kids just hate that boring old design part, don't you ? Much more interesting to just get in there and shit out some code. After all, you can always rewrite it again later a few times until you finally get it right. Never mind the cost of people's time that you waste in the process.
Flat files are neat, aren't they?
Not nearly as neat as properly designed software.
The model of having end users (and that includes everyone from the novice to the seasoned expert) manually editing text files to configure systems *as a matter of course* is stupid, broken and fundamentally unreliable. Heck, it's barely tolerable for trying to solve corner-case, special-needs problems.
Oh, my oh me. You know nothing about me OR my software.
Sure I do. You've been telling me all about the bad habits you have, how you prefer to fix problems reactively rather than proactively and how tied you are to a particular mindset.
Sorry. I forgot how humorless you were. Never mind (harrrumph). It's probably all that Microsoft dreck that's got you so grouchy. Hey, buy me a case of corona and I'll set up Slackware for you. It'll take only a couple of hours, but it'll make you SO much happier! I'm pretty sure your face won't crack if you grin, but we'll take it slow just in case.
Thanks, but my fleet of Linux servers are running quite well on their own, despite people like you trying to make that difficult.
The way you would allow the user to copy software from machine to machine despite the presence of a registry would be to NOT USE THE REGISTRY FOR THAT SOFTWARE. Meaning,
Look, all your objections to using flat files are straw man arguments.
No, they're not. The *only* redeeming feature "flat files" have is that they're "easier" (*very* much a relative term) to manually recover by hand in the case of disaster.
If I'm building an application and I want to set up a config file, it's trivially easy to set up an XML file, read it in and parse it.
Or you could just make a couple of API calls to the atomic, secure, system DB that someone else has already been nice enough to provide for you.
If I'm a halfway decent programmer, I'll be done in half an hour and it'll be perfect.
If by "perfect" you mean subject to all the problems I've already listed, plus be vulnerable to bugs in your reinventions of various wheels, then yes, it will be "perfect".
What makes it much better than your registry is that my USERS can edit the file themselves, because I TRUST THEM.
Then you're a fool. End users will, at every turn, try to break your software, either deliberately or accidentally. Bad input is the primary weapon they will utilise in these efforts.
See, I'm from New York, not Redmond. A user who just gave me money for something is my brand-new Best Friend. He can do whatever the hell he wants with my project; hell, he can print out the code and roll around naked in it for all I care.
Right. Because that way it's easier to just blame the end user for your badly written software.
The POINT is, using a registry makes you a pain in the ass. Your user can't just copy your install directory to his new computer. He has to go through your buggy installer. He loses all his settings. And so on.
Of course he can, assuming you, the developer, allow him to.
Using flat files means I'm NOT a pain in the ass. If one of MY users wants to copy my software to a new machine, he can just copy the directory and the config file over. Piece of cake, really.
Nothing about the Registry stops him doing that.