The models you are discussing are pretty much limited to information flows, and generally apply to the file space (including in-memory equivalents.)
This says nothing about whether, for instance, a process can change its own or another process scheduling priority, start/restart/shutdown a device, apply or ignore resource quota, etc.
In this respect, the "unix based model" I'm referring to is exactly 2 levels of privilege: normal user and superuser. VMS finer grained privileges allowed a user (or more accurately a process operating on behalf of a user) to get selected privileges to do specific things. Some that I remember (from way long ago) were: Start/Stop printer queues, Exceed Disk Storage Quotas, Change File Ownership/Permissions, Change Scheduling Parameters (i.e. process priority), lock pages into virtual memory (a favorite for tuning applicatins) and my favorite, Set Process Privileges (basically this was the meta-privilege, it was the privilege that allowed you to enable to disable other privileges...)
My bottom line: There's -a lot more- to OS security than just information flow controls, and I strongly believe that all of the OS I know/use today (including Win XP, Mac OS X, and various Linux/Posix flavors) are -all deficient- in this regard. For Windows, it's particularly disturbing given Dave Cutler and the VMS heritage.
dave
p.s. In the file space itself, VMS had a 4th permission bit, that prevented you from deleting the file. I still remember RWED as the order of the permissions (and I stopped using VMS in about 1984...) It turns out to be quite handy to say to a user "You can read/write this file, but you can't delete it." When you couple that with VMS file versioning, that provided a lot of help against accidental deletion of files by both fat-fingered users and inadvertently misbehaving software.
On another/. topic recently, there was a small discussion (claimer: I started it) on VMS fine grained security models. Apparently Win NT had something closer to the VMS model inside, but it apparently was never really used by anyone.
I still think this is what modern OS need. Unix-based security models are better implemented, but I do NOT think they're necessarily better designed.
Thus I think that there is merit in both the original poster's comments and this response, but the last line of this response should perhaps (in the best object oriented fashion) be applied to SELF as well as to PARENT.
I dunno. I find the whole PKI thing to be incredibly baroque and subject to failure/inconsistency/difficulty-of-use (what's the opposite of ease-of-use?).
Now maybe when I get it all set up right, it'll run OK. But so far getting it set up has proven to be a massive time sink for me, and I'm still not there yet.
I know about the D. Cutler connection with Win NT, which is why I mentioned it in my original post. If Windows does have a finer grained protection, it's sure not visible to me. Having administered VMS systems, I know how reasonablly easy it was to run a VMS system. That administrative ease-of-use from VMS certainly didn't transfer to Win NT, at least not in my experience. I've never seen any practical 'how to administer Win NT' guide that makes reference to a finer-grained protection model, nor did I see any evidence of its use in anything I've done with Win NT, Win 2k or Win XP.
Certainly when installing stuff on VMS, the documentation would say "The account used to install this application needs the following privileges:..." I've never seen anything similar on -anything- I've ever read on installing or administering Windows. So it seems to me that, if this were in Win NT, it was abandoned by Microsoft as something they used and promoted to the power user/administrator community. (A strength of VMS, by the way, was its ability to enable Power Users. I remember setting up accounts for people who could control printers, etc on behalf of themselves and others near them, so I didn't have to be bothered for all the administrative stuff with restarting print queues after refilling a printer that ran out of paper...)
Why is it that OS vendors have never really taken seriously fine-grained security models?
VMS (yes, VMS) showed just how effective this could be. If I remember right (and it's been a while), VMS provided about 25 different privileges, and you could mix-and-match to make sure that an installer, for example, ran with only the privileges it needed.
I'm disappointed that one of the things Apple did not add/improve in its adoption of Mach and other Unix concepts was a security model that was better than "privileged(root)/not privileged".
Although nothing MS does really shocks me, I'm still surprised that after the "Year of Security" emphasis from Microsoft this didn't come out as a core part of Vista.
I'm also disappointed this doesn't seem to be a topic of discussion in current Operating System research. Can anyone point me to good new work on establishing and then implementing more fine-grained OS privileges? About the only advance here I know about are Access Control Lists, etc. applied to the file system. That's great for file security, but doesn't help much for the rest of the operating environment...
How long will it be before the Culture Nazis in Ottawa start requiring ISPs, etc, to prioritize their notion of "Canadian Content" over other traffic on the net?
What's next: Every 4th byte of traffic passed by an ISP has to originate in Canada?
Gee, I remember being tech editor for a POSIX standard 15 years ago and being quite efficient at collaborating to produce that document across the country. Other POSIX standards that I contributed to (as a reviewer) were developed across the world. It -is- nice that Word provides diff marks, but we had those in Scribe and troff 20 years ago...
And yes I've configured LDAP, on OS X Server. It wasn't the easiest thing I've done (but it's a lot easier than configuring PKI certificates).
That's where WinTel and the rise of the 'CIO Culture' coincided. WinTel produced products optimized to make CIOs important, CIOs grew important trying to make WinTel, particularly Windows, work. The Intel part makes gigabucks on supporting each new product, that provides additional demands on computers. (Truly, what do you do now that requires several orders of magnitude more computational power than you did 10 years ago? If you're like most people, running email, word processing, low compexity spreadsheets, simple graphics programs for presentations and the like, I'd assert "not much." Sure we have more glitz, but does anyone think that MS Word now is that much more functional than MS Word 5 was on Windows 95???)
CIOs and Micro$oft have been an evil combination. CIOs gain authority by fielding systems that have some sense of 'business case' but that require expensive tech support staff. Windows moves capabilities away from end users and to CIOs and corporate overhead. End users get stuck with problems that only CIOs can fix, but the CIO -never- has to pay for employee downtime when the computer goes south. In the meantime, the Microsoft monopoly grows, and no CIO gets fired for buying Microsoft, no matter how bad the crap from Redmond is (and there has been some -real crap- from Redmond.)
This clearly started with WinNT's focus on 'the managed user experience' and was obvious to me by 2000. So I'm only surprised it's taken others so long. Geez, and they talk about -Steve Jobs'- reality distortion field!!
dave (they get my Mac when they pry it from my cold, dead fingers, -or- they indemnify me against all of the delay, downtime and inconvenience of the alternatives...)
I believe a big part of our problem is our piss-poor set of programming langauges and their support for concurrency. C/C++ threads packages and Java's low level synchronization primitives make developing parallel/concurrent programs much more difficult than it should be. (Ada95/Ada05 gets it better, at least by raising the level of abstraction and supporting one approach to unifying concurrency synchronization, concurrency avoidance, and object-oriented programming.)
Additionally, there's the related problems of understanding concurrency. In the 80's and 90s in particular, there were a lot of fundamental research results in reasoning about concurrent systems. Nancy Lynch's work at MIT (http://theory.csail.mit.edu/tds/lynch-pubs.html) comes to my mind. I'm always dismayed at how little both new CS grads and practicing programmers know about distributed systems, and how poor their ability is collectively to reason about concurrency. It seems like most of the time when I say "race condition" or "deadlock", eyes glaze over and I have to go back and explain 'concurrency 101' to folks who I think should know this.
Wasn't it Jim Gray (I sure hope he shows up safe and sound!) who coined the terms "Heisenbugs" and "Bohrbugs" to help describe concurrency and faults? (Wikipedia attributes this to Bruce Lindsay, http://en.wikipedia.org/wiki/Heisenbug) Not only is developing concurrent programs hard, debugging them is -really hard-, and our tools (starting with programming languages and emphasizing development tools/checkers), should be focused on substantially reducing or elminating the need for debugging, or development effort will continue to grow.
Until we have more powerful tools -and training- (both academic and industrial) in using those tools, the Sapir-Whorf hypothesis (http://en.wikipedia.org/wiki/Sapir-Whorf_hypothes is) will apply: The lack of a language (programming language as well as 'spoken language') to talk about concurrency will make it nearly impossible for most programmers to develop concurrent programs. This applies to both MIMD and SIMD kinds of parallelism.
This is actually a kinda serious question. Zombification can occur through social engineering attacks on even the most secure system (it's that damn biological IO unit that's the weak point.)
Can anyone cite successful attacks on Macs turning them into Bots? (I'd feel much more comfortable defending my own machines if I knew of what has happened to others...)
My first thought was "Well, only those who have experience with both operating systems are entitled to have an opinion; millions of people who have never run anything but Windows XP or Vista are not qualified to compare to something they don't know."
Then I said, "OK, so -how do you- compare operating systems for end-user machines?"
And I think this is the valid question. End-user OS need to be evaluated along a whole series of considerations, some of which could be quantitative, and others such as consistency of the user experience, are probably more qualitative.
But I now admit to my bias: I very much prefer OS X for a couple of reasons ('power user' of OS X vice 'normal user' of Win XP):
(1) quality of the overall user experience (mentioned in the MIT "Technology Review" article, http://www.technologyreview.com/Infotech/17992/pag e1/ )
(2) reliability (but still not quite 100%)
(3) security/anti-virus etc
(4) support for -2- paradigms: Apple Mac GUI, and traditional Unix shell. About once a week I pop into the shell and do something that would be painful, annoying or even impossible to do from the GUI. I've installed the old Cygwin stuff on WinNT, but it's definitely NOT the same as having a real Unix kernel and shell.
But I've never programmed in either environment (all my development work was done on traditional Unix, but I'm Very Grateful for the new Aquamacs port of Emacs to OS X), nor have I done any performance assessment of either OS. So I hereby disqualify myself from having a -fully valid- opinion on this topic.
Your Mileage May Vary, but at least there's a reasonable way to measure that mileage. When it comes to OS evaluation, can anyone point to credible asssessment methodologies? (Who was it that said "If you can't measure it, it's not science." Lord Kelvin?)
But I'd assert we -know- how to do better software, both on the specification side (requirements, system engineering, system architecture) and the implementation side. But we are still too beholden to old inefficient technologies, old ways of doing things, and impossible schedules that prevent us from starting on the right foot, even if it would deliver the end product in less time than it actually takes. (Personal case in point: I believe that having to use a debugger is a sign of -failure- as an engineer, although again I suspect that's a minority opinion. Applying a debugger means "I don't know what my software is actually doing." I much prefer to specify and implement to specifications, and prefer technologies that eschew debuggers in favor of design-time and compile-time checking. Debugging is a -piss-poor- use of time...)
(Reader poll: For successful products, what's the ratio of actual time to budgeted time? For almost every successful project I know of, it's much more than 1.0. And that's especially true as a function of size; the larger the product, the larger the actual/budget ratio. In my experience we're better at estimating as engineers, but failures at selling those estimates to management.)
These are two separate parts of the problem, and need separate solutions.
Yes users suck at generating requirements. At the same time, classic programmers aren't very good at it either, and this is part of the disciplines of software-intensive system engineering and architecture that the industry as a whole has not done well. But for an example of where this -does work-, look at Apple.
But more importantly in my view, at least for most of you reading this, is that current software implementation really sucks the big one. The implementation community needs to get better at the following:
1. verifying completeness and implementability of requirements - do we know what we're supposed to build?
2. designing and implementing code to meet those requirements - doing what must work
3. designing and implementing code that is "safe" - making sure that the program does not do something unexpected or wrong. "wrong" here is against both formal 'what the program must do' specifications (i.e. no segfaults/BSODs), and also against the principle of 'least surprise', where there's a hole in the specs, the program should not do things like "remove all files from the disk drive..."
4. as a special case of #3, designing and implementing code that can be 'safety deployed' in an expected environment - that includes the hostile environment of the internet for applications that run on networked machines (i.e. no buffer overflows)
Finally, we have to learn how to do this within cost & schedule. For managers, that means better prediction skills. For implementers, that means more effective tools to reduce time-to-market and in particular time-to-market-for-a-working-product.
A key part of this is a sea change to accept that fielding programs with known deficiencies should be unacceptable, both professionally and legally, and the obligation to test and verify programs to a credible independent standard.
The analogies to other kinds of engineering applies. Structural engineers design and test/verify using specific standards against clearly defined practices (e.g. snow loading depends on where you put the building, just ask folks in Colorado about this right now:-) We need better standards of delivery for my items 1..4, and then we need means, both professional and legal, to enforce them.
I'm in a probable minority (certainly a minority among those I've talked to about this), but I think we need licensing of software engineers, with the equivalent assumption of professional enginering liability. (Yes I have a pretty good idea what that means, my father was a structural engineer in private practice and I understand from him what his professional liabilities were and how much he paid for that liability insurance.)
For the program I work on, there was a deliberate move from PowerPC to x86, and the bottom line justification was performance per watt and the related significant advantages in cooling. There were some potential cost savings, but the cost of the chip was not a primary discriminator. For embedded computing applications, size, weight and power (SWaP) concerns dominate. The secondary consideration was software availability. There are some items that are just not available for PowerPC, and we were unsuccessful in getting a vendor to consider a port of their X86 Linux product to PPC Linux. (This program is an 800 lb gorilla, but the vendor wouldn't budge. I guess it's "gorilla vs elephant" and the elephant won.)
Apple has given performance/watt as one of their justifications, too. (Ability to run Windoze is clearly another big advantage, and I'm looking forward to a new MacBook Pro where I can suffer the occasional Windoze-only application while having my Mac cake too.)
Now I know IBM claims to have engineering breakthroughs in PPC performance & cooling, and we certainly saw substantial benefits to the PPC architecture particularly for floating point performance. But for about 2/3 of our apps, integer performance (where x86 does better) predominates, and one thing we really do NOT want to do for logistical reasons is to support multiple CPUs. That's both a development and a field support/supply nightmare.
I dunno about this one. I've been pricing alternatives to replace my dead "token PC". By the time I start with a base machine and put stuff into it to make it usable, I'm easily at the price of a Mac Mini. And if I needed a monitor, adding a -good- monitor to the configuration would get me to an iMac.
Any more the prices for Macs are equivalent to -similarly equipped, quality- hardware. That's not to say you can't go to Fly-by-nite Computers and get a clone box thrown together for a lot less. The last 3 'token PCs' in my home network have all failed in less than 2 years, while I routinely get 4-6 years from each Mac I've owned.
> Wait until 30 years from now when the US is a much browner country. When white people are the minority, let's see how they feel about racial profiling.
Well, my wife is Hispanic (no one would mistake me for "brown"). We lived in Canada (Vancouver) for a couple of years, where she suffered much more from 'profiling' and discrimination than anywhere in the US. Not because she was Hispanic, but because she was mistaken for Sikh/Punjabi. It was bad enough to be followed around by store detectives, but when she used to get crap from the old Sikhs because they thought she was Sikh gone western, that was too much. There were areas of town that she refused to go without me because of this.
People have to acknowledge that (1) transportation has proven to be the real Achilles's Heel of modern society, and (2) no one is forcing you to travel to the US.
Now some of the government responses, both US and UK, have been very onerous. (Connected through Heathrow lately???)
I for one will not let the threat of terrorism stop me from travelling. And if I'm travelling internationally, I fully expect that in exchange for entry to another country, I'll have to forgoe privacy, etc. It's part of the trade for living in the modern world.
How many people who don't like these kinds of broad-band searches think that targeting/profiling is more acceptable?
So with Mac Office fatally crippled (Most documents I get these days have macros in them. I have no clue why, but I get the anti-virus warning when I open them), I'll be forced to go to something that can open that crap.
With Parallels or BootCamp, I -can- run Windows and Windows Office on my Mac. But at what cost??? Dell pays peanuts for Windows/Office on each machine it ships. Me, I'll have to buy retail. Office XP Pro costs $300 (I just priced it out for -this very reason-.) That'a an appalling amount of money for (bad) software. Office on Windows retail probably costs a similar amount. Corporate IT tells me "Oh, we -never- buy software from Microsoft. We always get our machines equipped by the OE(hardware)M."
Good strategy if you're a Microsoft stockholder.
But the previous comments about the antitrust "oversight" of Microsoft applies here, and I find Office a much more insidious monopoly than Windows ever was...
Microsoft does a pretty good job documenting public APIs (Yes, I said something nice about MS).
If so-called professional programmers choose to ignore them, the risk should be on the programmers and the companies who hire them. Implementing "within the lines" should be a key part of any programmer's ethics and skills, especially when they're getting paid.
Of course, one would wish that Microsoft would actually follow existing standards, instead of making their own standards for things like OS APIs... But that does not excuse those who ignore the published public API documentation.
Well, no matter how bad Microsoft looks, it has -nothing- on the big record companies for bare naked greed.
At least there are people at Microsoft who actually labor to produce the product, and who profit from the results (but how many, and the relationship between contractor contributions and MS employees has been a topic of much discussion...) The big record labels serve only to market the products of others on a contract basis.
Slashdot Mirror
I guess we're at cross-purposes here.
The models you are discussing are pretty much limited to information flows, and generally apply to the file space (including in-memory equivalents.)
This says nothing about whether, for instance, a process can change its own or another process scheduling priority, start/restart/shutdown a device, apply or ignore resource quota, etc.
In this respect, the "unix based model" I'm referring to is exactly 2 levels of privilege: normal user and superuser. VMS finer grained privileges allowed a user (or more accurately a process operating on behalf of a user) to get selected privileges to do specific things. Some that I remember (from way long ago) were: Start/Stop printer queues, Exceed Disk Storage Quotas, Change File Ownership/Permissions, Change Scheduling Parameters (i.e. process priority), lock pages into virtual memory (a favorite for tuning applicatins) and my favorite, Set Process Privileges (basically this was the meta-privilege, it was the privilege that allowed you to enable to disable other privileges...)
My bottom line: There's -a lot more- to OS security than just information flow controls, and I strongly believe that all of the OS I know/use today (including Win XP, Mac OS X, and various Linux/Posix flavors) are -all deficient- in this regard. For Windows, it's particularly disturbing given Dave Cutler and the VMS heritage.
dave
p.s. In the file space itself, VMS had a 4th permission bit, that prevented you from deleting the file. I still remember RWED as the order of the permissions (and I stopped using VMS in about 1984...) It turns out to be quite handy to say to a user "You can read/write this file, but you can't delete it." When you couple that with VMS file versioning, that provided a lot of help against accidental deletion of files by both fat-fingered users and inadvertently misbehaving software.
On another /. topic recently, there was a small discussion (claimer: I started it) on VMS fine grained security models. Apparently Win NT had something closer to the VMS model inside, but it apparently was never really used by anyone.
I still think this is what modern OS need. Unix-based security models are better implemented, but I do NOT think they're necessarily better designed.
Thus I think that there is merit in both the original poster's comments and this response, but the last line of this response should perhaps (in the best object oriented fashion) be applied to SELF as well as to PARENT.
dave
I dunno. I find the whole PKI thing to be incredibly baroque and subject to failure/inconsistency/difficulty-of-use (what's the opposite of ease-of-use?).
Now maybe when I get it all set up right, it'll run OK. But so far getting it set up has proven to be a massive time sink for me, and I'm still not there yet.
dave
Give this guy some points for insight...
dave
I know about the D. Cutler connection with Win NT, which is why I mentioned it in my original post. If Windows does have a finer grained protection, it's sure not visible to me. Having administered VMS systems, I know how reasonablly easy it was to run a VMS system. That administrative ease-of-use from VMS certainly didn't transfer to Win NT, at least not in my experience. I've never seen any practical 'how to administer Win NT' guide that makes reference to a finer-grained protection model, nor did I see any evidence of its use in anything I've done with Win NT, Win 2k or Win XP.
..." I've never seen anything similar on -anything- I've ever read on installing or administering Windows. So it seems to me that, if this were in Win NT, it was abandoned by Microsoft as something they used and promoted to the power user/administrator community. (A strength of VMS, by the way, was its ability to enable Power Users. I remember setting up accounts for people who could control printers, etc on behalf of themselves and others near them, so I didn't have to be bothered for all the administrative stuff with restarting print queues after refilling a printer that ran out of paper...)
Certainly when installing stuff on VMS, the documentation would say "The account used to install this application needs the following privileges:
dave
Sure sounds like Apple pegged it right... ( http://www.apple.com/getamac , specifically the "security" ad :-)
dave
Why is it that OS vendors have never really taken seriously fine-grained security models?
VMS (yes, VMS) showed just how effective this could be. If I remember right (and it's been a while), VMS provided about 25 different privileges, and you could mix-and-match to make sure that an installer, for example, ran with only the privileges it needed.
I'm disappointed that one of the things Apple did not add/improve in its adoption of Mach and other Unix concepts was a security model that was better than "privileged(root)/not privileged".
Although nothing MS does really shocks me, I'm still surprised that after the "Year of Security" emphasis from Microsoft this didn't come out as a core part of Vista.
I'm also disappointed this doesn't seem to be a topic of discussion in current Operating System research. Can anyone point me to good new work on establishing and then implementing more fine-grained OS privileges? About the only advance here I know about are Access Control Lists, etc. applied to the file system. That's great for file security, but doesn't help much for the rest of the operating environment...
dave
How long will it be before the Culture Nazis in Ottawa start requiring ISPs, etc, to prioritize their notion of "Canadian Content" over other traffic on the net?
What's next: Every 4th byte of traffic passed by an ISP has to originate in Canada?
dave
Gee, I remember being tech editor for a POSIX standard 15 years ago and being quite efficient at collaborating to produce that document across the country. Other POSIX standards that I contributed to (as a reviewer) were developed across the world. It -is- nice that Word provides diff marks, but we had those in Scribe and troff 20 years ago...
And yes I've configured LDAP, on OS X Server. It wasn't the easiest thing I've done (but it's a lot easier than configuring PKI certificates).
Note that LDAP != Microsoft Active Directory.
dave
That's where WinTel and the rise of the 'CIO Culture' coincided. WinTel produced products optimized to make CIOs important, CIOs grew important trying to make WinTel, particularly Windows, work. The Intel part makes gigabucks on supporting each new product, that provides additional demands on computers. (Truly, what do you do now that requires several orders of magnitude more computational power than you did 10 years ago? If you're like most people, running email, word processing, low compexity spreadsheets, simple graphics programs for presentations and the like, I'd assert "not much." Sure we have more glitz, but does anyone think that MS Word now is that much more functional than MS Word 5 was on Windows 95???)
CIOs and Micro$oft have been an evil combination. CIOs gain authority by fielding systems that have some sense of 'business case' but that require expensive tech support staff. Windows moves capabilities away from end users and to CIOs and corporate overhead. End users get stuck with problems that only CIOs can fix, but the CIO -never- has to pay for employee downtime when the computer goes south. In the meantime, the Microsoft monopoly grows, and no CIO gets fired for buying Microsoft, no matter how bad the crap from Redmond is (and there has been some -real crap- from Redmond.)
This clearly started with WinNT's focus on 'the managed user experience' and was obvious to me by 2000. So I'm only surprised it's taken others so long. Geez, and they talk about -Steve Jobs'- reality distortion field!!
dave (they get my Mac when they pry it from my cold, dead fingers, -or- they indemnify me against all of the delay, downtime and inconvenience of the alternatives...)
I believe a big part of our problem is our piss-poor set of programming langauges and their support for concurrency. C/C++ threads packages and Java's low level synchronization primitives make developing parallel/concurrent programs much more difficult than it should be. (Ada95/Ada05 gets it better, at least by raising the level of abstraction and supporting one approach to unifying concurrency synchronization, concurrency avoidance, and object-oriented programming.)
s is) will apply: The lack of a language (programming language as well as 'spoken language') to talk about concurrency will make it nearly impossible for most programmers to develop concurrent programs. This applies to both MIMD and SIMD kinds of parallelism.
Additionally, there's the related problems of understanding concurrency. In the 80's and 90s in particular, there were a lot of fundamental research results in reasoning about concurrent systems. Nancy Lynch's work at MIT (http://theory.csail.mit.edu/tds/lynch-pubs.html) comes to my mind. I'm always dismayed at how little both new CS grads and practicing programmers know about distributed systems, and how poor their ability is collectively to reason about concurrency. It seems like most of the time when I say "race condition" or "deadlock", eyes glaze over and I have to go back and explain 'concurrency 101' to folks who I think should know this.
Wasn't it Jim Gray (I sure hope he shows up safe and sound!) who coined the terms "Heisenbugs" and "Bohrbugs" to help describe concurrency and faults? (Wikipedia attributes this to Bruce Lindsay, http://en.wikipedia.org/wiki/Heisenbug) Not only is developing concurrent programs hard, debugging them is -really hard-, and our tools (starting with programming languages and emphasizing development tools/checkers), should be focused on substantially reducing or elminating the need for debugging, or development effort will continue to grow.
Until we have more powerful tools -and training- (both academic and industrial) in using those tools, the Sapir-Whorf hypothesis (http://en.wikipedia.org/wiki/Sapir-Whorf_hypothe
dave
This is actually a kinda serious question. Zombification can occur through social engineering attacks on even the most secure system (it's that damn biological IO unit that's the weak point.)
Can anyone cite successful attacks on Macs turning them into Bots? (I'd feel much more comfortable defending my own machines if I knew of what has happened to others...)
dave
My first thought was "Well, only those who have experience with both operating systems are entitled to have an opinion; millions of people who have never run anything but Windows XP or Vista are not qualified to compare to something they don't know."
g e1/ )
Then I said, "OK, so -how do you- compare operating systems for end-user machines?"
And I think this is the valid question. End-user OS need to be evaluated along a whole series of considerations, some of which could be quantitative, and others such as consistency of the user experience, are probably more qualitative.
But I now admit to my bias: I very much prefer OS X for a couple of reasons ('power user' of OS X vice 'normal user' of Win XP):
(1) quality of the overall user experience (mentioned in the MIT "Technology Review" article, http://www.technologyreview.com/Infotech/17992/pa
(2) reliability (but still not quite 100%)
(3) security/anti-virus etc
(4) support for -2- paradigms: Apple Mac GUI, and traditional Unix shell. About once a week I pop into the shell and do something that would be painful, annoying or even impossible to do from the GUI. I've installed the old Cygwin stuff on WinNT, but it's definitely NOT the same as having a real Unix kernel and shell.
But I've never programmed in either environment (all my development work was done on traditional Unix, but I'm Very Grateful for the new Aquamacs port of Emacs to OS X), nor have I done any performance assessment of either OS. So I hereby disqualify myself from having a -fully valid- opinion on this topic.
Your Mileage May Vary, but at least there's a reasonable way to measure that mileage. When it comes to OS evaluation, can anyone point to credible asssessment methodologies? (Who was it that said "If you can't measure it, it's not science." Lord Kelvin?)
dave
OK, so what's a "Hokie", really (and is it something one would really want as a school mascot?)
dave
Of course, the whole point of a one-night-stand is to get fucked.
dave
If that qualifies as a "boon to mankind". OK. :-)
dave
Interesting.
But I'd assert we -know- how to do better software, both on the specification side (requirements, system engineering, system architecture) and the implementation side. But we are still too beholden to old inefficient technologies, old ways of doing things, and impossible schedules that prevent us from starting on the right foot, even if it would deliver the end product in less time than it actually takes. (Personal case in point: I believe that having to use a debugger is a sign of -failure- as an engineer, although again I suspect that's a minority opinion. Applying a debugger means "I don't know what my software is actually doing." I much prefer to specify and implement to specifications, and prefer technologies that eschew debuggers in favor of design-time and compile-time checking. Debugging is a -piss-poor- use of time...)
(Reader poll: For successful products, what's the ratio of actual time to budgeted time? For almost every successful project I know of, it's much more than 1.0. And that's especially true as a function of size; the larger the product, the larger the actual/budget ratio. In my experience we're better at estimating as engineers, but failures at selling those estimates to management.)
dave
These are two separate parts of the problem, and need separate solutions.
:-) We need better standards of delivery for my items 1..4, and then we need means, both professional and legal, to enforce them.
Yes users suck at generating requirements. At the same time, classic programmers aren't very good at it either, and this is part of the disciplines of software-intensive system engineering and architecture that the industry as a whole has not done well. But for an example of where this -does work-, look at Apple.
But more importantly in my view, at least for most of you reading this, is that current software implementation really sucks the big one. The implementation community needs to get better at the following:
1. verifying completeness and implementability of requirements - do we know what we're supposed to build?
2. designing and implementing code to meet those requirements - doing what must work
3. designing and implementing code that is "safe" - making sure that the program does not do something unexpected or wrong. "wrong" here is against both formal 'what the program must do' specifications (i.e. no segfaults/BSODs), and also against the principle of 'least surprise', where there's a hole in the specs, the program should not do things like "remove all files from the disk drive..."
4. as a special case of #3, designing and implementing code that can be 'safety deployed' in an expected environment - that includes the hostile environment of the internet for applications that run on networked machines (i.e. no buffer overflows)
Finally, we have to learn how to do this within cost & schedule. For managers, that means better prediction skills. For implementers, that means more effective tools to reduce time-to-market and in particular time-to-market-for-a-working-product.
A key part of this is a sea change to accept that fielding programs with known deficiencies should be unacceptable, both professionally and legally, and the obligation to test and verify programs to a credible independent standard.
The analogies to other kinds of engineering applies. Structural engineers design and test/verify using specific standards against clearly defined practices (e.g. snow loading depends on where you put the building, just ask folks in Colorado about this right now
I'm in a probable minority (certainly a minority among those I've talked to about this), but I think we need licensing of software engineers, with the equivalent assumption of professional enginering liability. (Yes I have a pretty good idea what that means, my father was a structural engineer in private practice and I understand from him what his professional liabilities were and how much he paid for that liability insurance.)
dave
For the program I work on, there was a deliberate move from PowerPC to x86, and the bottom line justification was performance per watt and the related significant advantages in cooling. There were some potential cost savings, but the cost of the chip was not a primary discriminator. For embedded computing applications, size, weight and power (SWaP) concerns dominate. The secondary consideration was software availability. There are some items that are just not available for PowerPC, and we were unsuccessful in getting a vendor to consider a port of their X86 Linux product to PPC Linux. (This program is an 800 lb gorilla, but the vendor wouldn't budge. I guess it's "gorilla vs elephant" and the elephant won.)
Apple has given performance/watt as one of their justifications, too. (Ability to run Windoze is clearly another big advantage, and I'm looking forward to a new MacBook Pro where I can suffer the occasional Windoze-only application while having my Mac cake too.)
Now I know IBM claims to have engineering breakthroughs in PPC performance & cooling, and we certainly saw substantial benefits to the PPC architecture particularly for floating point performance. But for about 2/3 of our apps, integer performance (where x86 does better) predominates, and one thing we really do NOT want to do for logistical reasons is to support multiple CPUs. That's both a development and a field support/supply nightmare.
dave
I dunno about this one. I've been pricing alternatives to replace my dead "token PC". By the time I start with a base machine and put stuff into it to make it usable, I'm easily at the price of a Mac Mini. And if I needed a monitor, adding a -good- monitor to the configuration would get me to an iMac.
Any more the prices for Macs are equivalent to -similarly equipped, quality- hardware. That's not to say you can't go to Fly-by-nite Computers and get a clone box thrown together for a lot less. The last 3 'token PCs' in my home network have all failed in less than 2 years, while I routinely get 4-6 years from each Mac I've owned.
dave
> Wait until 30 years from now when the US is a much browner country. When white people are the minority, let's see how they feel about racial profiling.
Well, my wife is Hispanic (no one would mistake me for "brown"). We lived in Canada (Vancouver) for a couple of years, where she suffered much more from 'profiling' and discrimination than anywhere in the US. Not because she was Hispanic, but because she was mistaken for Sikh/Punjabi. It was bad enough to be followed around by store detectives, but when she used to get crap from the old Sikhs because they thought she was Sikh gone western, that was too much. There were areas of town that she refused to go without me because of this.
dave
People have to acknowledge that (1) transportation has proven to be the real Achilles's Heel of modern society, and (2) no one is forcing you to travel to the US.
Now some of the government responses, both US and UK, have been very onerous. (Connected through Heathrow lately???)
I for one will not let the threat of terrorism stop me from travelling. And if I'm travelling internationally, I fully expect that in exchange for entry to another country, I'll have to forgoe privacy, etc. It's part of the trade for living in the modern world.
How many people who don't like these kinds of broad-band searches think that targeting/profiling is more acceptable?
dave
So with Mac Office fatally crippled (Most documents I get these days have macros in them. I have no clue why, but I get the anti-virus warning when I open them), I'll be forced to go to something that can open that crap.
With Parallels or BootCamp, I -can- run Windows and Windows Office on my Mac. But at what cost??? Dell pays peanuts for Windows/Office on each machine it ships. Me, I'll have to buy retail. Office XP Pro costs $300 (I just priced it out for -this very reason-.) That'a an appalling amount of money for (bad) software. Office on Windows retail probably costs a similar amount. Corporate IT tells me "Oh, we -never- buy software from Microsoft. We always get our machines equipped by the OE(hardware)M."
Good strategy if you're a Microsoft stockholder.
But the previous comments about the antitrust "oversight" of Microsoft applies here, and I find Office a much more insidious monopoly than Windows ever was...
dave
If so-called professional programmers choose to ignore them, the risk should be on the programmers and the companies who hire them. Implementing "within the lines" should be a key part of any programmer's ethics and skills, especially when they're getting paid.
Of course, one would wish that Microsoft would actually follow existing standards, instead of making their own standards for things like OS APIs... But that does not excuse those who ignore the published public API documentation.
dave
Well, no matter how bad Microsoft looks, it has -nothing- on the big record companies for bare naked greed.
At least there are people at Microsoft who actually labor to produce the product, and who profit from the results (but how many, and the relationship between contractor contributions and MS employees has been a topic of much discussion...) The big record labels serve only to market the products of others on a contract basis.
dave