"Equal Time" indeed...it should be equal, 0 hours on creationism (by whatever name) and 0 hours on evolution.
Leave biology out of school, you mean?
That's not that terrible of an idea. Put more time in mathematics and physics and chemistry; work on increasing the reading level of the students; use the time spent in biology classrooms to teach additional courses so that the average class size can go down.
There's nothing in high-school biology that's really _useful_ (unless it's the biology teachers who get saddled with sex-ed mandates). You don't learn anything about the scientific method, but you do spend a lot of time learning that you should respect the opinions of the authorities in a subject (this applies to the evolutionists, the creationists, and the intelligent design-ists -- "look, we're right, trust us!").
On the other hand, it's easy to demonstrate the utility of the Scientific Method in a physics class -- start with Aristotle's claim that heavy objects fall faster.... or better yet, start with the claim that all objects fall at the same speed, and then drop a lead weight and a small feather.
What are, after all, the important lessons from Science? How to handle being wrong gracefully is one of 'em, presumably. Not often practiced, but an essential skill in theory. Another lesson would be that one experiment isn't conclusive, because experiments are often flawed.
Provide a write-up of an experiment, but falsify the data.
Teach the students that they shouldn't trust the results of any experiment they can't replicate themselves with their own equipment. Rig some experiments with some sleight-of-hand. Teach the students that they can't trust their eyes. Etc. Etc. Etc.
So...
Less emphasis on "what we know" and more emphasis on "let's find out". And THAT would be teaching a _useful_ form of Science in the schools, rather than some sort of twisted authoritarianism subject to the political whim of the month.
Although it is amusing that someone would want Apple to borrow features from Microsoft instead of the (usual) other way 'round, I really would not most of the features suggested in the article. Please, no, the only thing worse than change for the sake of change is change to conform with a really bad standard.
Like everyone else, I'm going to look at the suggestions:
1) Compatible control keys.
Oh, please, no.
If it matters, then there should be an argument about which way is better, other than "more people are used to the Microsoft way". And if it doesn't matter, then it shouldn't be a big deal.
It isn't the labelling, but the position? Let's not muck around too much with the position, eh? It was an unmitigated disaster when some bozo decided that the control key ought to be on the same row as the space instead of to the left of the "A" key; let's not continue the trend of rendering the standard keyboard unusable.
If you want a different layout, remap the keys yourself, or buy a different keyboard. Line up to buy one of the Optimus keyboards if they come out next year, and map all of the keys to exactly where you want them.
If I were paranoid, I'd say that this suggestion was designed to drive the sorts of people who haven't been appropriately indoctrinated into the Microsoft Windows Way[tm] away from computers entirely. If I had to use the Dell keyboard that came with the machine at work, I'd probably be contemplating a job that didn't involve computers, and wouldn't for the foreseeable future.
2) Save button on toolbars.
As has been pointed out, this is an application thing, not an OS thing.
Personally, I'm not a big fan of toolbars. Trying to puzzle out the little icons isn't a profitable use of my time (and! yet! here! I! am! on! slashdot! yeah, yeah, I get the irony.), so I'd just as soon have the option to get rid of the toolbars and reclaim that screen real-estate for getting actual work done.
Finally, the appropriate solution would be to give the user the choice of setting up the toolbar (like Mail.app) with every possible leaf in the menu-tree. Why bicker about "save", when all the leaves in the menu should be allowable targets for the user to put into the toolbar?
3) A multi button mouse
Hardware request. Bogus objection.
What I want is a freaking three-button mouse with a scroll-wheel, where the scroll-wheel isn't trying to double-up as the third button. Yes, I know, I can "just click on the scroll-wheel", but I don't want to. I also don't want tiny little buttons that I can use with my thumb or pinky or whatever. I'm not looking for a funky keyboard on my mouse, after all (which is where this eternally-growing-button-list trend goes).
But if the OS works with a single-button mouse, fine. Why should that be a problem? You want people who do best with a single-button mouse to have a terrible time with their computer? Such sadism makes for a very poor UI, and is no doubt part of the reason I bailed out of the Microsoft-centric world-view many years ago.
4) Only show relevant file types in open and save dialogs.
Many applications ghost out "inappropriate" files already. But making the actual hiding of information a system default is just bad form -- I get extremely annoyed when my computer hides information from me.
Which leads into this nonsense of "hiding file extensions". THEY ARE NOT FREAKING EXTENSIONS: THE ARE SUFFIXES!
Yes, boys and girls, it's the height of idiocy to look at the NAME of a file to determine how to handle it when you can look in a file to see what sort of thing it actually is. One of the stupidest "features" of Microsoft Windows is it's inability to understand that a JPEG file is actually a JPEG file even thought it's named "Foo", or, gosh darn it, even maliciously renamed to "Foo.GIF".
It's refreshing to see an honest review when a reviewer doesn't like a book. However, when I got to:
The book as a whole, particularly with its monotonous small text and a complete lack of the simplest illustrations or even eye-catching chapter header graphics, feels like a dry collegiate dissertation written by someone who could give a damn about the subject matter and just needs a passing grade.
...my perception of the whole review underwent a phase-change. It's not a rant, it's a whine.
Of all the things to object to, this one shouldn't even have made the list. It's a book. It mean for those who can read. And this particular complaint puts me in mind of a child complaining about how "real books" are "too hard".
Most of my library is full of great books that lack the simplest illustrations (even though I have more than a shelf's worth of Hellboy, Sandman, Far Side, Calvin & Hobbes, and suchlike; lest you get the wrong idea, be assured that I'm not opposed to illustrations) or eye-catching chapter-header graphics. I like books where the type is monotonous; anything eye-catching catches my eye, disturbs my reading, and derails my concentration.
Some of the worst books I've encountered rely on ever-changing fonts, plentiful illustrations, eye-catching graphics, all to hide the fact that the author isn't saying much, or even saying it well.
If the reviewer has come to rely on that sort of reading experience, perhaps it's because they've not been reading the right sort of books. Put down those technical manuals and pick up a volume of Wodehouse. Set aside that Learn-in-21-days tome and grab some Kipling. Whatever you do, go read something by someone who can entrance you with words, where the illustrations are created by your own imagination, where what catches your eye is the next sentence, and the next, and the next...
This isn't to say that the book may be any good. I don't know, I haven't read it. I can imagine that it's a hard thing to do, to identify and discuss the themes of SF movies, much less more than one or two, in a single book. To cover the genre would likely result in a three-inch coffee-table book, four columns of tiny (monotonic!) type on every family-bible-thin page.
If anything slows Linux's desktop adoption, it's Linux, not OS X.
Yup. And as Linux tries to grab a bigger piece of the pie, it's going to lose supporters. Being all things to all people is a way to be nothing to everyone.
In general, people who buy Macs are not the same ones who install Linux, Jamie Zawinski and/. OS hackers not withstanding.
The local linux user's group
(KPLUG)
has a strong showing of people who have Apple Powerbooks at the meetings. It seems that many people don't like the idea of being expected to sit in only one camp.
Sure, most users will blindly type in a password if a software installer asks them to, but what about an e-mail attachment or random internet site?
True, but if they run an email attachment, the obvious (to me, at least) thing to do would be to drop a program in a dot-file, and then modify the user's.tcshrc/.bashrc so that some later login, it pops the dialog, after prompting with an error message appearing to be from the system.
"A critical security update is needed for your $RANDOM_APP. The update has been downloaded. Installing update..."
[Password Dialog Here]
Or somesuch.
It would be better if the OS provided customizable permissions (grant networking access seperately from hard drive access, for example), but I've yet to see a good security setting setup or user interface to allow that sort of thing...
I think that's the sort of thing a security-minded expert would prefer, and the average user would be overwhelmed by.
It would also be nice if you could 'spoof' root access to trick software into thinking it has full access to your system.
Yes, it would. I believe that Debian kinda-sorta does this with "fakeroot". I'd like an actual sandbox...
For instance, the OS could intercept all calls to update files outside of a folder called "buggy-app" on the desktop, and use an overlay file system and copy-on-write to store the changes in a special directory.
Yup! I've been pondering the need for this sort of thing for awhile. If it's clean enough, and robust enough, you can run _all_ of your applications in their own sandboxes. I think that this approach is simple enough to work for both the average home user and powerful enough to make a security guru happy.
Only the spoofed program would use the files that it created and modified, and the changes it performed could be reversed by deleting the stuff the OS put in/tmp...
Exactly. And if you want to keep the changes, you can put it in $HOME/.sandboxes/appname, or, since we're on the Mac, perhaps $HOME/Sandboxes/Appname/...
2. they require entering the admin password for significant changes whereas XP is happy for you to run as admin 24/7 without further confirmation of any actions.
Any application can pop a dialog asking for the admin password, and more programs all the time are doing so.
Tried to install any applications lately (like, say, OpenOffice)? The installer demands administrator access, and will REFUSE to continue unless it gets it. Even if you're only going to install it into/tmp or $HOME to check it out.
Try to compile F95 in GCC? You might be instructed to download a DMG of "up to date" cctools. But when you mount the drive, you get an installer, and this installer also demands administrator access, presumably so it can stomp on the tools already installed. And it's non-obvious where you go to get the source that will compile on the Mac so you can install it in a place of your own choosing.
Mac users are slowing being trained to be as dumb as MSWindows users. When the pretty little dialog asks for the administrator password, just provide it, otherwise you won't be able to play, and the maintainers of that package will mock you. Caution? What's that? Prudence? Soooo old-school. Paranoia? Get a life!
There's not much difference between being trained to grant a program administrative status every time it asks for it and running as the administrator all the time. It just adds a ten-second delay before your machine is compromised, and people can point at you and wonder aloud why you didn't _know_ what the program was going to do before it did it.
I'm not giving up my Mac in favor of anything out of Redmond. I just want a stick I can beat developers with when they write installers that demand administrative access and refuse to go further until they get it. If the user declines to give the administrative password, then let them choose where to install your software, and give them a README on what they can do "by hand" to integrate your software. IF they so choose.
Why not? Many people abuse telephone network by tying up lines for hours at a time, so what?
Why not? Because it's the bloody network.
Unless you encrypt your traffic, you're doing the equivalent of using a party line (phone metaphor) or sending postcards (snail mail metaphor). Anyone who has access may listen in/read without let or hindrance. That's why there is no expectation of privacy.
You want privacy on the network? Encrypt. With an algorithm that YOU choose.
It does not allow the phone company to record and sell conversations.
You're mixing arguments here. Recording and selling conversations is not part of the expectation of privacy. I may not be able to reasonably expect privacy, but I can expect that works that I create will belong to me, and may not be used without compensation.
You, a random user, aren't allowed to record and sell conversations without permission, much less the phone company. If you want to push the metaphor in that direction, you'll have to agree to a law making it illegal for you to record a conversation without my explicit prior approval, coupled with periodic notification that my conversation is being "recorded".
This will probably necessitate DRM... how do I know that you didn't take a screen-shot of the conversation after I logged off?... It just gets messy. Better to invent new metaphors, than to push the old ones too far.
First, should a multi-core processor chip count as more than one CPU. Second, should software be licensed on a per-CPU basis.
I think it's obvious that a multi-core processor chip should count as multiple CPUs. Arguments otherwise seem to equate a "chip" and "CPU", something laughably oversimplified. You can have "processors" that involve no chips at all (remember TTL "CPU boards"?), or that are made up of dozens of chips -- so there is really no inherent relation between "processor" and "chip".
Put a dual-core chip, or a quad-core chip, into your machine, and you have to deal with the same issues as a dual-processor or quad-processor machine.
[I would love to see how many 6502s or 6800s could fit in the space of a "modern CPU" die, possibly with some RAM on-chip for each "core". Play the games with clock speed on top of all that, and it might be something quite interesting to program for.]
The second issue is harder, and shouldn't be allowed to influence the definition of what is or is not a "CPU". If you don't agree with per-CPU licenses, then don't fudge the definition of "CPU", rail against the real grip: per-CPU licenses. If you do claim to agree with per-CPU licenses but are too cheap to actually PAY them once you get a machine with multiple CPUs, stop trying to muddy the water by claiming your multiple-CPU machine really isn't a multiple-CPU machine.
If your concern is that *all* new machines will eventually end up as multiple-CPU machines, that's yet another legitimate concern, but if you chase the bleeding edge, you're going to bleed. Don't pretend to be suprised by it.
Personally, I don't much care for multiple-CPU licenses. I'd rather deal with a per-machine, per-user, per-organization, or site license. But not all businesses want to play that game, and that's okay, so long as there's always an alternative.
I've come to the opinion that under all but the most extraordinary circumstances, a company should not work on developing custom applications in-house. They should either farm them out to a development company, or they should adjust their processes to work with existing Commercial Off The Shelf (COTS) applications. Concentrate on your core business and you're probably better off. If your core business is not software, you probably can't do a successful software project.
I have an instictive bad reaction to advice that includes "adjust... processes to work with existing... applications". Bending your business to fit some piece of software instead of bending the software to fit your business doesn't seem like a good idea to me.
However, that is not necessarily an argument against COTS, just an argument against changing things to fit the software instead of finding the software that fits.
I don't disagree (much) with the major premise -- companies should only rarely develop their own software -- but I think that the size of the company should also be taken into account. A Very Large company should probably maintain a staff of programmers that understand and maintain the software; being beholden to COTS (can vanish in an instant, or be purchased by competitors) or an external development company just seems like a Really Bad Idea.
As the company gets smaller, the need for software decreases, until at some level, one person is able to run a business without any software at all. Somewhere between the two extremes there's a crossover point.
In the ideal world, as the cost of software exceeds the cost of a programmer, a company could employ programmers to create, maintain, and adapt open-source software, add a layer of the proprietary business logic, and they'd get the best of COTS and local development, and everyone would win.
In other cases I was supporting products developed by another division of the company. These products ran part of the order processing system, but were so buggy that the two of us supporting it literally couldn't take lunch at the same time because various components required constant maintenance.
Did not the maintenance make the product better over time? Or do you mean that you had to do things like "whoops! module XYZ crashed, restore from tape, remove the offending record from the input data set, restart" ?
And advantage of local programmers is that bugs can be fixed when discovered in something approaching reasonable time, presuming that the source is available, the build environment built, and a non-junior programmer has had time to understand the code. The disadvantage is that a non-junior programmer might get bored and "improve" things...
An external development/maintenance shop is a sort of happy medium -- but perhaps the most fragile solution. You're tied to a specific, customized, optimized "solution", maintained by a company that can go out of business for a variety of reasons, or get so much business that you become a minor customer and you lose the flexibility and customization as the major customers direct control.
Moderating. Using pageup/pagedown to move. Didn't realize that this was also changing the settings from something positive (insightful/interesting/funny) to negative (overrated/etc.)
So, a post. This will, as I understand it, undo those moderations I have made. Oh, well. Better none than a false down. Hope this works.
That's a matter of exactness. Most people say "all" or "everyone", but actually mean "99.9%" or "everyone I know/care about".
True. And it would have been different if the response had been "We don't care about you, you're not in our target demographic, and we'd wish you'd just go away."
Of course, I also think a lot of people say "all" or "everyone" when they actually mean "55% or more", and say "most" if they mean "40% or more".
There is a point where I agree with them. I've around 1000 players in my game. I will certainly care for something that matters to 10 of them. Whether or not I care for something that only one person dislikes depends entirely on my mood.
b) I have gone to great pains to make sure my pages are useable to non-javascript users. The javascript-reliant features won't work, so (for example) the low-frame status bar won't update for you. You lose a feature, but you don't lose the entire site.
...indicates that you are both careful and skilled, and I wish more people made that sort of effort. Point (c) falls under (b) in the sense that the error reporting will be better with javascript than without -- so? It will still work without, which is all that is needed.
d) The point was that there are some places where all parties find it more convenient, easier and generally better with than without Javascript. . .
The problem is that I've been on the wrong side of that, and was informed that all parties found it more convenient. Except that I didn't, therefore, the assertion was too strong. I was willing to put up with a less shiney, less flashy, less interactive system, no worries, but I wasn't given the choice, because "all of our customers prefer the new system".
If you truly can get all parties to agree, then you're dealing with a closed system, and it makes sense to do whatever you want. That still leaves the question as to how ill-equipped are the users to make informed decisions? (Presumably, if they've hired you, they've hired you for your expertise, and you are their informed decision.)
And as it's a closed system, you could just as well get away with a standalone application. "Live data" and "untrusted programs" don't apply anymore.
As to point (a) -- telnet is more convenient, at least to me, than ssh, in that I can monitor the network to see what's actually going across the wire, and when. It helps tremendously when you're trying to debug a network problem... but that's just my point of view.
You mean, "join the herd", apparently. But that applies everywhere -- don't like Microsoft windows? Get a grip, it's used all over the place. Don't like x86? Get a grip, it's what dominates the market. Prefer something like Opera or OmniWeb over Internet Explorer? Get a grip, IE won the browser war. Got a problem with Active-X? Get a grip, it makes things so much more convenient and responsive....
Javascript can be used to save a round trip to the server.
Yes. But that's an optimization, which is not _essential_ in terms of correctness and minimum-level usability. I agree that it can improve the end-user's experience, should they choose to enable Javascript. I agree that it can make the site much more responsive for the end-user, should they choose to enable Javascript.
Of course, if they don't enable Javascript, the site is just broken, so there's no improvement at all, and to such a user, the "improved" site is far worse than the old one.
This goes equally for your comments on client side validation.
You have to verify all that data again on the server and provide an appropriate response in case of missing or invalid information. It's redundant. This isn't necessarily bad, so long as some bright programmer doesn't eliminate the redundancy by yanking it out of the server-side (Look! It speeds things up!).
This means that users who disable javascript might have three or four submissions that are rejected by the server instead of the nice realtime "this is what you have missing" interface that you get with javascript, but That's Okay, if that's what they choose.
But only the ignorant or the incompetent rely on client-side validation. It's potentially useful as an optimization, but that's it.
For some people usability is what counts.
Exactly. And if I disable Javascript -- my computer, my choice, right? (if not, I expect you to be running a system that can handle ActiveX and aren't using anything like a popup blocker) -- many sites that rely on Javascript are totally unusable.
But you know what? Dissable Javascript then go back and try to use the form again*.
This is exactly what I would consider desirable behavior. It Still Works. It may work better and smoother and more pleasing with Javascript, but it's not Required. It may save a lot on bandwidth and wall-clock time with Javascript, but it's not Required -- I can pay for that additional bandwidth, or sit around the extra five seconds waiting for a page to refresh, if I so choose.
I don't mind someone else using javascript (so long as they don't whine about cross-site scripting attacks, annoying popups, pr0n pages that Won't Go Away, and suchlike) if they choose to take the risks. My only problem is with web-site developers that demand that users enable javascript.
Probably right, though many very convenient features do.
I do not dispute that.
A lot of unconvenient features are also possible with Javascript as well, so the convenience argument cuts both ways.
It's really, really, really convenient to have trusted live data. You can get up to all sorts of neat tricks. Of course, it's also really convenient to skip all this nonsense about accounts and passwords; it's convenient to use telnet instead of ssh; it's convenient to leave your keys in your car, or to do away with keys entirely and just have a 'starter button'.
The downside is that you get a lot of "I didn't mean for THAT to happen". The consequences of convenience are paid somewhere.
Nevertheless, there are a few places where Javascript is very handy. I could probably find a way to do it without Javascript, but it would be much more work and hassle for me, less convenient for the user, and more error-prone.
Well, as I disable/filter-out Javascript, it won't work at all for me, which makes such pages REALLY inconvenient. So "less convenient for the user" isn't really a good point.
It's less convenient for you, in that it's more work and hassle. But then, checking for possible errors, avoiding buffer overflows, and all that fun stuff is also more work and hassle than assuming everything will work correctly all of the time. There are times when that's okay (only you will be using your programs and you don't mind the extra work when you run the program), and there are times when it isn't (Aunt Tillie uses a proxy that filters out all javascript to protect her from cross-site scripting attacks).
Standard programming tradeoff. Someone has to put up with the hassle; should it be the users, or the programmers?
This all boils down to a Javascript vulnerability.
Yup. It further demonstrates why any financial institution that requires you to enable javascript in order to use their website should be deemed incompetent.
If web masters would stop NEEDLESSLY using Javascript to do things like open new windows, and would use it ONLY when there is no way using HTML to accomplish the same goal, then people would not need to have Javascript active all the time, and the impact of exploits like this would be greatly reduced.
I assert that no essential behavior on a web-page requires Javascript -- it's ALL needless. Want to take the window to a new page? Standard anchor tags do that. Want to open up a new page/tab/browser instead? Surely that's the user's choice, and all of the modern GUI browsers I'm aware of give the user that ability.
"Features" provided by Javascript fall into a very few categories, so far as I can tell:
Client-side verification
This includes validating that all the fields in a form are filled in, as well as checking that the user entered the correct password. Naturally, this is the silliest reason to require Javascript, as the validation step still has to be done on the server side anyway, making the client-side validation a redundant convenience at best, and an addle-brained sign of utter incompetence at worst.
Eye-Candy
This includes dynamic "feedback", drop-down menus, etc. None of this is what you can call "essential", even if it's very nice and garners rave reviews from the average user.
Replacing standard HTML functionality
This includes opening new windows/tabs, following links, submitting forms, and suchlike. This is perhaps the most aggravating reason to require javascript, as it artifically narrows the potential user community of the website.
Essentially, the categories are "Don't Do", "Don't need", and "Redundant".
However, I think it's almost a lost cause.
I think the only way we're going to convince webmasters to think twice about Javascript is to build a runtime debugger/replacement tool into the Javascript VMs in our browsers. Let the user specify wholesale replacement of javascript fragments (e.g. remove the open-window-in-a-popup portion of a tag and replace it with a good old-fashioned anchor tag) and changing of values in the running script (e.g. let's just change that discount from 5% to 95%).
It's my computer after all, and I should get a say in what programs run on my computer, no?
Perhaps you should read it again: "makes me want to see" isn't the same thing as "ought to". What I *really* want to see is an abandonment of the sort of attitude I referred to.
Sooner or later, we're all going to suffer as a result of those attitudes. Been there, done that, don't want to see it again. The Let Us Bash Every Other Operating System crowd already spreads enough ill-will so that the backlash is annoying -- so go swear at them, eh? I have cornflakes to throw out.
Besides, it's only money. Surely you don't _object_ to paying for software? Linux is about free-as-in-speech, not free-as-in-beer, right? At least that's what I'm told....
Re:Go back to sleep. You have no "natural allies"
on
Sun-isms Debunked
·
· Score: 1
In the corporate world there is no such thing as "natural allies". Especially not with competing products.
An ally isn't necessarily a friend. And in the corporate world, I do think there are "natural allies", especially in situations where sole monopoly status is detrimental.
But generally, when a business man/woman shakes your hand, you can bet his/her other hand is behind his/her back, holding a dagger.
I wouldn't bet -- but it's certainly the safest thing to assume.
Some people claim the the purpose of a business is to make money. Others claim that the purpose of a business is to stay in business, and making money is a necessary sub-goal. If you're dealing with someone who believes the former, there's not only a knife in the hand behind their back, there's one up their sleeve...
People, this is not Tolkien....
Real world is nowhere near that simple.
I'd rather get my ethics from Tolkien than Rand, though. And you're quite correct -- the Real World isn't nearly as simple as we'd like.
Anyway.
Good points, though. Although I think your model of Sun ("Oh, look, we can rule! Let's kill Linux!") is an oversimplification itself. I think Sun is trying to walk a fine line between retaining its own identity and fostering symbiosis with open-source.
FYI: your comment comes across as just as unreasonable the comment you were reacting to.
Well, yes. But "I think you're a tad hostile." doesn't really get the point across.
Do I really want to see SCO sue every Linux user? No. But neither do I want to see such extreme and needless hostility. I don't want to belong to that sort of a community.
For a start, it is not reasonable to equate the minority of loud-mouthed Linux advocates on/. with the Linux community.
True.
But the loud-mouthed advocates become the voice of the community, unless the community takes great care.
Second, you are "wishing ill" on the Linux community because they (in your mind) they "wish ill" on Sun.
Balance is important.:)
IMO, the best way to deal with malignant / ignorant "advocates" is to ignore them.
I respectfully disagree. Silence implies assent. Ignoring the rabid advocates gives 'em credibility -- not with the community, granted, but with those outside the community.
I don't want to see "Linux user == hates Sun" established as a meme in the general population.
Well, Sun picked this fight, not the Linux Community.
Not from where I'm standing. I watched consultants sell businesses on the idea of replacing their Sun machines with Linux boxes (which is only slightly better, if at all, from the point of view of Sun, than replacing those Sun machines with NT boxes).
As far as I can tell (remember, boys and girls, the plural of anecdote is not 'data', so remember your salt), Linux didn't really show up on the Sun radar until it started displacing Sun machines, once the Linux advocates discovered it was a lot easier selling companies on replacing Sun servers instead of Microsoft desktops.
Note that "the Linux community" is a bit of a misnomer; it doesn't speak with one voice about *anything*. (Which means that it's a bit silly for us, the members of this community, to expect the same from anyone else.)
We pick on Sun because they're explicitly attacking Linux community ideals.
How involved do you have to get before you're allowed to point out that the emperor has no clothes?
They've open-sourced application software, they've set up alternative community-involvement models, and they're on the point of open-sourcing their flagship software.... I think they're at the point of having the credentials in order to submit a little criticism.
(Don't get me wrong, I don't think Sun is perfect; but then, I don't think any group is, so a little tolerance is necessary. Log in your own eye and all that.)
It's my guess that the majority of the Anti-Sun camp are made up of All-The-World-Should-Be-x86 and All-The-World-Should-Be-Linux groups, with a leavening of all-businesses-are-evil types. (Those seem to be the primary three legs of the argument presented by those folks who tell me I shouldn't use a Sun machine.) But that's a guess, and how can I begin to test it?
Sun is not anti-Linux, Sun sells Linux, Sun will even sell you a full rack of x86 servers all running Linux. Get over it, Slashdot!
Amen.
I think some people have taken the joke of "world dominance" a little to seriously.
I blame the impatience of youth.
Re:It's all about the hardware
on
Sun-isms Debunked
·
· Score: 4, Insightful
Their expensive high-end hardware? Why is that a problem? High-end hardware is reliable, degrades gracefully under load, and detects incipient failures. If you're actually using computers to make money (as opposed to scamming folks), these are useful features to have. And, eventually, many of those technologies trickle-down to consumer-level hardware, so everyone wins.
If a tenth of the money spent on making the x86-64 crap work were spent on optimizing the SPARC systems, we'd have have ultra-cheap SPARC CPUs for the commodity market.... SPARC has been 64-bit for a long time now. The x86 is a johnny-come-lately to this arena, and is still playing catch-up.
Slashdot Mirror
That's not that terrible of an idea. Put more time in mathematics and physics and chemistry; work on increasing the reading level of the students; use the time spent in biology classrooms to teach additional courses so that the average class size can go down.
There's nothing in high-school biology that's really _useful_ (unless it's the biology teachers who get saddled with sex-ed mandates). You don't learn anything about the scientific method, but you do spend a lot of time learning that you should respect the opinions of the authorities in a subject (this applies to the evolutionists, the creationists, and the intelligent design-ists -- "look, we're right, trust us!").
On the other hand, it's easy to demonstrate the utility of the Scientific Method in a physics class -- start with Aristotle's claim that heavy objects fall faster.... or better yet, start with the claim that all objects fall at the same speed, and then drop a lead weight and a small feather.
What are, after all, the important lessons from Science? How to handle being wrong gracefully is one of 'em, presumably. Not often practiced, but an essential skill in theory. Another lesson would be that one experiment isn't conclusive, because experiments are often flawed.
Provide a write-up of an experiment, but falsify the data. Teach the students that they shouldn't trust the results of any experiment they can't replicate themselves with their own equipment. Rig some experiments with some sleight-of-hand. Teach the students that they can't trust their eyes. Etc. Etc. Etc.
So...
Less emphasis on "what we know" and more emphasis on "let's find out". And THAT would be teaching a _useful_ form of Science in the schools, rather than some sort of twisted authoritarianism subject to the political whim of the month.
Like everyone else, I'm going to look at the suggestions:
1) Compatible control keys.
Oh, please, no.
If it matters, then there should be an argument about which way is better, other than "more people are used to the Microsoft way". And if it doesn't matter, then it shouldn't be a big deal.
It isn't the labelling, but the position? Let's not muck around too much with the position, eh? It was an unmitigated disaster when some bozo decided that the control key ought to be on the same row as the space instead of to the left of the "A" key; let's not continue the trend of rendering the standard keyboard unusable.
If you want a different layout, remap the keys yourself, or buy a different keyboard. Line up to buy one of the Optimus keyboards if they come out next year, and map all of the keys to exactly where you want them.
If I were paranoid, I'd say that this suggestion was designed to drive the sorts of people who haven't been appropriately indoctrinated into the Microsoft Windows Way[tm] away from computers entirely. If I had to use the Dell keyboard that came with the machine at work, I'd probably be contemplating a job that didn't involve computers, and wouldn't for the foreseeable future.
2) Save button on toolbars.
As has been pointed out, this is an application thing, not an OS thing.
Personally, I'm not a big fan of toolbars. Trying to puzzle out the little icons isn't a profitable use of my time (and! yet! here! I! am! on! slashdot! yeah, yeah, I get the irony.), so I'd just as soon have the option to get rid of the toolbars and reclaim that screen real-estate for getting actual work done.
Finally, the appropriate solution would be to give the user the choice of setting up the toolbar (like Mail.app) with every possible leaf in the menu-tree. Why bicker about "save", when all the leaves in the menu should be allowable targets for the user to put into the toolbar?
3) A multi button mouse
Hardware request. Bogus objection.
What I want is a freaking three-button mouse with a scroll-wheel, where the scroll-wheel isn't trying to double-up as the third button. Yes, I know, I can "just click on the scroll-wheel", but I don't want to. I also don't want tiny little buttons that I can use with my thumb or pinky or whatever. I'm not looking for a funky keyboard on my mouse, after all (which is where this eternally-growing-button-list trend goes).
But if the OS works with a single-button mouse, fine. Why should that be a problem? You want people who do best with a single-button mouse to have a terrible time with their computer? Such sadism makes for a very poor UI, and is no doubt part of the reason I bailed out of the Microsoft-centric world-view many years ago.
4) Only show relevant file types in open and save dialogs.
Many applications ghost out "inappropriate" files already. But making the actual hiding of information a system default is just bad form -- I get extremely annoyed when my computer hides information from me.
Which leads into this nonsense of "hiding file extensions". THEY ARE NOT FREAKING EXTENSIONS: THE ARE SUFFIXES!
Yes, boys and girls, it's the height of idiocy to look at the NAME of a file to determine how to handle it when you can look in a file to see what sort of thing it actually is. One of the stupidest "features" of Microsoft Windows is it's inability to understand that a JPEG file is actually a JPEG file even thought it's named "Foo", or, gosh darn it, even maliciously renamed to "Foo.GIF".
5) Sort folders to top of directory listings
Th
Of all the things to object to, this one shouldn't even have made the list. It's a book. It mean for those who can read. And this particular complaint puts me in mind of a child complaining about how "real books" are "too hard".
Most of my library is full of great books that lack the simplest illustrations (even though I have more than a shelf's worth of Hellboy, Sandman, Far Side, Calvin & Hobbes, and suchlike; lest you get the wrong idea, be assured that I'm not opposed to illustrations) or eye-catching chapter-header graphics. I like books where the type is monotonous; anything eye-catching catches my eye, disturbs my reading, and derails my concentration.
Some of the worst books I've encountered rely on ever-changing fonts, plentiful illustrations, eye-catching graphics, all to hide the fact that the author isn't saying much, or even saying it well.
If the reviewer has come to rely on that sort of reading experience, perhaps it's because they've not been reading the right sort of books. Put down those technical manuals and pick up a volume of Wodehouse. Set aside that Learn-in-21-days tome and grab some Kipling. Whatever you do, go read something by someone who can entrance you with words, where the illustrations are created by your own imagination, where what catches your eye is the next sentence, and the next, and the next...
This isn't to say that the book may be any good. I don't know, I haven't read it. I can imagine that it's a hard thing to do, to identify and discuss the themes of SF movies, much less more than one or two, in a single book. To cover the genre would likely result in a three-inch coffee-table book, four columns of tiny (monotonic!) type on every family-bible-thin page.
Which wouldn't necessarily be a bad thing.
"A critical security update is needed for your $RANDOM_APP. The update has been downloaded. Installing update..."
[Password Dialog Here]
Or somesuch.
I think that's the sort of thing a security-minded expert would prefer, and the average user would be overwhelmed by. Yes, it would. I believe that Debian kinda-sorta does this with "fakeroot". I'd like an actual sandbox... Yup! I've been pondering the need for this sort of thing for awhile. If it's clean enough, and robust enough, you can run _all_ of your applications in their own sandboxes. I think that this approach is simple enough to work for both the average home user and powerful enough to make a security guru happy. Exactly. And if you want to keep the changes, you can put it in $HOME/.sandboxes/appname, or, since we're on the Mac, perhaps $HOME/Sandboxes/Appname/...I like the way you're thinking.
Still... if there's no user involved, it's more of a worm, not a virus.
Tried to install any applications lately (like, say, OpenOffice)? The installer demands administrator access, and will REFUSE to continue unless it gets it. Even if you're only going to install it into /tmp or $HOME to check it out.
Try to compile F95 in GCC? You might be instructed to download a DMG of "up to date" cctools. But when you mount the drive, you get an installer, and this installer also demands administrator access, presumably so it can stomp on the tools already installed. And it's non-obvious where you go to get the source that will compile on the Mac so you can install it in a place of your own choosing.
Mac users are slowing being trained to be as dumb as MSWindows users. When the pretty little dialog asks for the administrator password, just provide it, otherwise you won't be able to play, and the maintainers of that package will mock you. Caution? What's that? Prudence? Soooo old-school. Paranoia? Get a life!
There's not much difference between being trained to grant a program administrative status every time it asks for it and running as the administrator all the time. It just adds a ten-second delay before your machine is compromised, and people can point at you and wonder aloud why you didn't _know_ what the program was going to do before it did it.
I'm not giving up my Mac in favor of anything out of Redmond. I just want a stick I can beat developers with when they write installers that demand administrative access and refuse to go further until they get it. If the user declines to give the administrative password, then let them choose where to install your software, and give them a README on what they can do "by hand" to integrate your software. IF they so choose.
Unless you encrypt your traffic, you're doing the equivalent of using a party line (phone metaphor) or sending postcards (snail mail metaphor). Anyone who has access may listen in/read without let or hindrance. That's why there is no expectation of privacy.
You want privacy on the network? Encrypt. With an algorithm that YOU choose.
You're mixing arguments here. Recording and selling conversations is not part of the expectation of privacy. I may not be able to reasonably expect privacy, but I can expect that works that I create will belong to me, and may not be used without compensation.You, a random user, aren't allowed to record and sell conversations without permission, much less the phone company. If you want to push the metaphor in that direction, you'll have to agree to a law making it illegal for you to record a conversation without my explicit prior approval, coupled with periodic notification that my conversation is being "recorded".
This will probably necessitate DRM... how do I know that you didn't take a screen-shot of the conversation after I logged off? ... It just gets messy. Better to invent new metaphors, than to push the old ones too far.
There are two issues here, not one.
First, should a multi-core processor chip count as more than one CPU. Second, should software be licensed on a per-CPU basis.
I think it's obvious that a multi-core processor chip should count as multiple CPUs. Arguments otherwise seem to equate a "chip" and "CPU", something laughably oversimplified. You can have "processors" that involve no chips at all (remember TTL "CPU boards"?), or that are made up of dozens of chips -- so there is really no inherent relation between "processor" and "chip".
Put a dual-core chip, or a quad-core chip, into your machine, and you have to deal with the same issues as a dual-processor or quad-processor machine.
[I would love to see how many 6502s or 6800s could fit in the space of a "modern CPU" die, possibly with some RAM on-chip for each "core". Play the games with clock speed on top of all that, and it might be something quite interesting to program for.]
The second issue is harder, and shouldn't be allowed to influence the definition of what is or is not a "CPU". If you don't agree with per-CPU licenses, then don't fudge the definition of "CPU", rail against the real grip: per-CPU licenses. If you do claim to agree with per-CPU licenses but are too cheap to actually PAY them once you get a machine with multiple CPUs, stop trying to muddy the water by claiming your multiple-CPU machine really isn't a multiple-CPU machine.
If your concern is that *all* new machines will eventually end up as multiple-CPU machines, that's yet another legitimate concern, but if you chase the bleeding edge, you're going to bleed. Don't pretend to be suprised by it.
Personally, I don't much care for multiple-CPU licenses. I'd rather deal with a per-machine, per-user, per-organization, or site license. But not all businesses want to play that game, and that's okay, so long as there's always an alternative.
However, that is not necessarily an argument against COTS, just an argument against changing things to fit the software instead of finding the software that fits.
I don't disagree (much) with the major premise -- companies should only rarely develop their own software -- but I think that the size of the company should also be taken into account. A Very Large company should probably maintain a staff of programmers that understand and maintain the software; being beholden to COTS (can vanish in an instant, or be purchased by competitors) or an external development company just seems like a Really Bad Idea.
As the company gets smaller, the need for software decreases, until at some level, one person is able to run a business without any software at all. Somewhere between the two extremes there's a crossover point.
In the ideal world, as the cost of software exceeds the cost of a programmer, a company could employ programmers to create, maintain, and adapt open-source software, add a layer of the proprietary business logic, and they'd get the best of COTS and local development, and everyone would win.
Did not the maintenance make the product better over time? Or do you mean that you had to do things like "whoops! module XYZ crashed, restore from tape, remove the offending record from the input data set, restart" ?And advantage of local programmers is that bugs can be fixed when discovered in something approaching reasonable time, presuming that the source is available, the build environment built, and a non-junior programmer has had time to understand the code. The disadvantage is that a non-junior programmer might get bored and "improve" things...
An external development/maintenance shop is a sort of happy medium -- but perhaps the most fragile solution. You're tied to a specific, customized, optimized "solution", maintained by a company that can go out of business for a variety of reasons, or get so much business that you become a minor customer and you lose the flexibility and customization as the major customers direct control.
Or hire away the best developers.
Thanks for the advice, however. I wasn't aware that it was considered a bug; I thought it was just Yet Another Feature I Didn't Like.
Arg.
Ignore this post.
Moderating. Using pageup/pagedown to move. Didn't realize that this was also changing the settings from something positive (insightful/interesting/funny) to negative (overrated/etc.)
So, a post. This will, as I understand it, undo those moderations I have made. Oh, well. Better none than a false down. Hope this works.
Of course, I also think a lot of people say "all" or "everyone" when they actually mean "55% or more", and say "most" if they mean "40% or more".
Heh.You're better than, er, "most".If you truly can get all parties to agree, then you're dealing with a closed system, and it makes sense to do whatever you want. That still leaves the question as to how ill-equipped are the users to make informed decisions? (Presumably, if they've hired you, they've hired you for your expertise, and you are their informed decision.)
And as it's a closed system, you could just as well get away with a standalone application. "Live data" and "untrusted programs" don't apply anymore.
As to point (a) -- telnet is more convenient, at least to me, than ssh, in that I can monitor the network to see what's actually going across the wire, and when. It helps tremendously when you're trying to debug a network problem... but that's just my point of view.
Of course, if they don't enable Javascript, the site is just broken, so there's no improvement at all, and to such a user, the "improved" site is far worse than the old one.
You have to verify all that data again on the server and provide an appropriate response in case of missing or invalid information. It's redundant. This isn't necessarily bad, so long as some bright programmer doesn't eliminate the redundancy by yanking it out of the server-side (Look! It speeds things up!).This means that users who disable javascript might have three or four submissions that are rejected by the server instead of the nice realtime "this is what you have missing" interface that you get with javascript, but That's Okay, if that's what they choose.
But only the ignorant or the incompetent rely on client-side validation. It's potentially useful as an optimization, but that's it.
Exactly. And if I disable Javascript -- my computer, my choice, right? (if not, I expect you to be running a system that can handle ActiveX and aren't using anything like a popup blocker) -- many sites that rely on Javascript are totally unusable.And that's the root of the problem.
I don't mind someone else using javascript (so long as they don't whine about cross-site scripting attacks, annoying popups, pr0n pages that Won't Go Away, and suchlike) if they choose to take the risks. My only problem is with web-site developers that demand that users enable javascript.
A lot of unconvenient features are also possible with Javascript as well, so the convenience argument cuts both ways.
It's really, really, really convenient to have trusted live data. You can get up to all sorts of neat tricks. Of course, it's also really convenient to skip all this nonsense about accounts and passwords; it's convenient to use telnet instead of ssh; it's convenient to leave your keys in your car, or to do away with keys entirely and just have a 'starter button'.
The downside is that you get a lot of "I didn't mean for THAT to happen". The consequences of convenience are paid somewhere.
Well, as I disable/filter-out Javascript, it won't work at all for me, which makes such pages REALLY inconvenient. So "less convenient for the user" isn't really a good point.It's less convenient for you, in that it's more work and hassle. But then, checking for possible errors, avoiding buffer overflows, and all that fun stuff is also more work and hassle than assuming everything will work correctly all of the time. There are times when that's okay (only you will be using your programs and you don't mind the extra work when you run the program), and there are times when it isn't (Aunt Tillie uses a proxy that filters out all javascript to protect her from cross-site scripting attacks).
Standard programming tradeoff. Someone has to put up with the hassle; should it be the users, or the programmers?
"Features" provided by Javascript fall into a very few categories, so far as I can tell:
- Client-side verification
- Eye-Candy
- Replacing standard HTML functionality
Essentially, the categories are "Don't Do", "Don't need", and "Redundant".This includes validating that all the fields in a form are filled in, as well as checking that the user entered the correct password. Naturally, this is the silliest reason to require Javascript, as the validation step still has to be done on the server side anyway, making the client-side validation a redundant convenience at best, and an addle-brained sign of utter incompetence at worst.
This includes dynamic "feedback", drop-down menus, etc. None of this is what you can call "essential", even if it's very nice and garners rave reviews from the average user.
This includes opening new windows/tabs, following links, submitting forms, and suchlike. This is perhaps the most aggravating reason to require javascript, as it artifically narrows the potential user community of the website.
However, I think it's almost a lost cause.
I think the only way we're going to convince webmasters to think twice about Javascript is to build a runtime debugger/replacement tool into the Javascript VMs in our browsers. Let the user specify wholesale replacement of javascript fragments (e.g. remove the open-window-in-a-popup portion of a tag and replace it with a good old-fashioned anchor tag) and changing of values in the running script (e.g. let's just change that discount from 5% to 95%).
It's my computer after all, and I should get a say in what programs run on my computer, no?
Perhaps you should read it again: "makes me want to see" isn't the same thing as "ought to". What I *really* want to see is an abandonment of the sort of attitude I referred to.
Sooner or later, we're all going to suffer as a result of those attitudes. Been there, done that, don't want to see it again. The Let Us Bash Every Other Operating System crowd already spreads enough ill-will so that the backlash is annoying -- so go swear at them, eh? I have cornflakes to throw out.
Besides, it's only money. Surely you don't _object_ to paying for software? Linux is about free-as-in-speech, not free-as-in-beer, right? At least that's what I'm told....
Some people claim the the purpose of a business is to make money. Others claim that the purpose of a business is to stay in business, and making money is a necessary sub-goal. If you're dealing with someone who believes the former, there's not only a knife in the hand behind their back, there's one up their sleeve...
I'd rather get my ethics from Tolkien than Rand, though. And you're quite correct -- the Real World isn't nearly as simple as we'd like.Anyway.
Good points, though. Although I think your model of Sun ("Oh, look, we can rule! Let's kill Linux!") is an oversimplification itself. I think Sun is trying to walk a fine line between retaining its own identity and fostering symbiosis with open-source.
Do I really want to see SCO sue every Linux user? No. But neither do I want to see such extreme and needless hostility. I don't want to belong to that sort of a community.
True.But the loud-mouthed advocates become the voice of the community, unless the community takes great care.
Balance is important.I don't want to see "Linux user == hates Sun" established as a meme in the general population.
As far as I can tell (remember, boys and girls, the plural of anecdote is not 'data', so remember your salt), Linux didn't really show up on the Sun radar until it started displacing Sun machines, once the Linux advocates discovered it was a lot easier selling companies on replacing Sun servers instead of Microsoft desktops.
Note that "the Linux community" is a bit of a misnomer; it doesn't speak with one voice about *anything*. (Which means that it's a bit silly for us, the members of this community, to expect the same from anyone else.)
How involved do you have to get before you're allowed to point out that the emperor has no clothes?They've open-sourced application software, they've set up alternative community-involvement models, and they're on the point of open-sourcing their flagship software.... I think they're at the point of having the credentials in order to submit a little criticism.
(Don't get me wrong, I don't think Sun is perfect; but then, I don't think any group is, so a little tolerance is necessary. Log in your own eye and all that.)
It's my guess that the majority of the Anti-Sun camp are made up of All-The-World-Should-Be-x86 and All-The-World-Should-Be-Linux groups, with a leavening of all-businesses-are-evil types. (Those seem to be the primary three legs of the argument presented by those folks who tell me I shouldn't use a Sun machine.) But that's a guess, and how can I begin to test it?
I think some people have taken the joke of "world dominance" a little to seriously.
I blame the impatience of youth.
If a tenth of the money spent on making the x86-64 crap work were spent on optimizing the SPARC systems, we'd have have ultra-cheap SPARC CPUs for the commodity market.... SPARC has been 64-bit for a long time now. The x86 is a johnny-come-lately to this arena, and is still playing catch-up.
Oh, it's "squeeze", by the way.