That's actually one of the more annoying things they did.
After using real two-button mice for years, I have a habit of having a finger on each button. With the Mighty Mouse, ok, it's cool that it's a touch sensor, but it means I have to lift my left finger to make it a right button.
XML's draconian error handling has no place on the web.
That "draconian" error handling is causing problems how?
I consider it to be a good thing. If I forgot a closing tag, or something like that, an XML parser will tell me, and I can fix it. Even if a "tag soup parser" attacks it later, it will be more likely to do the right thing.
Yes, having a browser be able to tolerate errors is a good thing, as long as people continue to build things that aren't XHTML. The problem is, exactly which algorithm should a browser use to parse sloppy HTML? Different browsers will parse it in different ways.
And XML parsers are consistent enough, at this point, that if it doesn't break for you, it's not broken for anyone else. The whole reason for being flexible about what you receive is gone -- it's a bit like trying to tolerate broken ASCII (or Unicode).
XHTML isn't necessarily easier to parse than (valid) HTML.
Actually, it kind of is. You just fire an XML parser at it -- any XML parser -- and you have a DOM.
With HTML, you have to handle tons of quirks and cruft before you even get to the DOM -- where there's still plenty of quirks and cruft to handle before you attempt CSS...
Of course, it's not necessarily easier for browsers which don't support it, like IE, and... IE...
When they want to search for something, they "Google" it, the don't "Internet Explorer" it.
Which is exactly the point.
If they want to search for it, and it doesn't work, I imagine they'll assume something is wrong with their computer, or the Internet, or even their browser, if they know what that is.
And yes, Google.com has been down. And when this has happened, that was exactly the reaction.
They'll only understand that "I went to Google and it didn't work. What else can I use?"
No, they'll understand "I wanted to Google and it didn't work. How can I fix it?"
How they interpret "fix it" is up for debate. But I'm guessing Google is far, far more popular than IE right now.
Maybe the problem is that it's so easy to swap one search engine for another?
Consider: What if Myspace started doing that? How many people would actually drop Myspace for Facebook (who haven't already)?
Right. The appropriate place is onDocumentLoad, which is done by jQuery. I suppose there's still the possibility that a browser will show part of the document, while the rest is still loading...
The hack I've been doing, which isn't particularly friendly to non-Javascript users, is to disable elements I want to jQuery-ify, either with standard HTML form disabled attributes, or with display:none for links.
In the first place, if standards (HTML / CSS) had been designed right, we wouldn't need so many javascript workarounds.
Javascript isn't always a workaround -- it's a client-side programming language. That means you can, I don't know, write programs in it.
I don't think HTML or CSS need to be Turing-complete. I'd be a bit frightened if they were.
Excuse not to implement it: The user should decide!
I actually agree with this, but it's also a case where it's progressive enhancement. Leave the link target as something sane, and use a Javascript onClick handler.
Excuse not to implement it: SSI works just as well.
Bull.
Workaround: AJAX.
Which provides more than just this.
Granted, that's most of what people use it for, but it's far from the only possibility. Simplest thing I can think of is displaying how long ago a given event happened -- Javascript can update this dynamically, without having to hit the server at all.
Another example would be anything requiring live updates -- granted, it's a hack, but how would you implement a Comet-style push protocol in HTML/CSS? How would you implement a decent chat client without it?
I use Noscript and I don't even bother to explore sites that are totally borked without their Javascript crutch.
In other words, it doesn't even occur to you that Gmail might be useful.
Javascript is a tool. Like any tool, it can become a crutch, but it actually does provide things which are not possible -- and should never be possible -- with straight HTML/CSS.
It's a lovely ideal. But you code for IE or you learn to live on a diet of Ramen Noodles and Jolt Cola.
No, I code for IE when I'm being paid to.
But take intranet sites, or simple pseudo-desktop apps -- I can develop a web app about as well as I can a desktop GUI app, and then it's as cross-platform as the browser I target. Since people were expecting me to tell them to install some Visual Basic crap, it's not that big a deal to make them install Firefox.
Which is an entirely moot point when the browsers move even slower, and IE is pretty much stalled.
It takes years to resolve real problems, because they're too busy with edge cases (XML namespaces mess!) to pump out specs that are useful.
Which is actually useful, when you're that particular edge case.
XQuery has NOTHING to do with browsers. Its an XML API like DOM and XSLT
Which some browsers support natively -- or am I thinking of xpath?
no one actually has a full implementation. Everyone is guessing.
That is one case I think the w3c went wrong -- no reference implementation. (Oh, there's Amaya, but let's be serious.) And the Acid tests are a great idea, but always lagging behind.
However, having exactly one implementation is not good, and should not be the basis for a standard -- unless that is an open source (probably public domain) and ridiculously well-tested, in the real world. The BSD network stack is a good example of that.
The CSS Zen Garden is an example of that. They start from the structure, and then do the best layout they can from that. If they start from a photoshop made by a designer, then try to apply it, its going to be another story.
That should tell you something about the usefulness of Photoshop as a web design tool.
Effectively, it's less. You can actually write any local, offline app you want, and distribute it pretty much any way you want. You don't have to code it in Java, you only have to target their pseudo-JVM.
Contrast to the iPhone -- yes, you can write native apps, and technically, you can do anything you want. But Apple has a truly massive list of restrictions, plus their own unpredictable whim, which determines whether or not you can run them.
So, in every way that counts, Android is looking less restrictive. If the only restriction is that your app runs somewhat slower, I really don't care. If they are placing restrictions on how you use the network, that's still an order of magnitude less restrictive than the iPhone.
Well, if any of them have a wifi port, it shouldn't be too hard to write some sort of package manager app for it which doesn't go through the Google store. Or just to pull apps directly from the Internet, or from your own machine.
Did you have to open the case, or exploit the existing software at all?
It's the difference between installing Linux on a PC, and installing Linux on an Xbox.
Once all the reverse engineering is done, the PC requires that you put an Ubuntu DVD in it and follow the instructions. The Xbox requires various combinations of soldering, specific models of USB thumbdrives, owning a certain game, and avoiding a certain update.
That's what I mean by "lets". Does HTC just avoid helping? In that case, I'm not worried.
Or does HTC actively hinder, with things like trusted computing, DRM, etc? If Android phones do that, Android fails -- worse than the new MS "Open" XML.
"The Epson America website directs you to Epson Kowa for Linux drivers for their printers, including one for the CX5400. You can download their GPLd binaries and source code from here."
The Mac OSX file system supports as big a file as anyone could buy a disk drive to hold it.
CIFS stands for Common Internet FileSystem. It's the new version of SMB. Without it, you indeed cannot read files bigger than 4 gigs from a Samba share, or from a shared folder on Windows.
What is the use of another file system for most users?
A fair question, but beside the point. You asked if there was software that wouldn't run on OS X, and there is.
And to answer that question, the use of another filesystem is if you have files stored on that other filesystem. If I need to recover files from a dead hard drive, I boot a Linux livecd, confident that it can read any filesystem I throw at it. Even if OS X had a livecd that would run on non-Mac hardware, it wouldn't be able to read either the XFS or the ext3 filesystem on this hard drive.
Who would want to use that when the GUI of OSX is far better?
Opinion, not fact. I like KDE, and I intensely dislike the OS X GUI.
Most free Mac software comes on DMG a disk image that opens and installs the software with a few mouse clicks.
Which is both unintuitive (tons of people just run them from the disk image, instead of dragging it to applications) and not a package manager.
Dependencies, reverse-dependencies, automatic updates (or manual updates of the entire system with a single click/command), actual uninstallation (do I drag it to the trash? Do I find the.mpkg?), huge repositories of known-good software (as in, not malicious), trivially scriptable for setting up a new, custom installation exactly the way you want, without resorting to disk images.
You could argue that none of the above things are needed -- which would be kind of like claiming none of the advanced features of Photoshop are really needed, and we should all be content with the Gimp. If your main argument is that features aren't needed, you've already lost.
I happen to like those features. In particular, there's no way in hell I'm going back to checking each of 10 or 20 free Mac programs for updates manually, by going to the website.
I loved Enterprise for being the one Star Trek where they couldn't fall back on the Prime Directive as an excuse to never actually make a political statement.
Unfortunately, it also had that other thing I hate so much about Trek -- all the temporal plots. Yawn!
Slashdot Mirror
The advantage of FireWire 400 over USB is extremely minimal
And FireWire 800?
That's actually one of the more annoying things they did.
After using real two-button mice for years, I have a habit of having a finger on each button. With the Mighty Mouse, ok, it's cool that it's a touch sensor, but it means I have to lift my left finger to make it a right button.
If you make them think, their heads might explode from cognitive dissonance.
Not much chance of making them think...
(Full disclosure: I used a Powerbook for over a year. I don't mind OS X nearly as much as I do Windows.)
I have never seen a digital camera with good video.
Or the more expensive one that now has firewire.
"Nearly equal" to FireWire 400.
The Macbook Pro has FireWire 800, which is pretty much twice as fast.
USB 3.0 will be faster, but it's not out yet. Which means that the fastest peripheral port it has is half what it was in the last Macbooks.
Technically, the gigabit is faster, I suppose...
XHTML was a good idea, poorly executed.
So... your response is to throw it out wholesale?
XML's draconian error handling has no place on the web.
That "draconian" error handling is causing problems how?
I consider it to be a good thing. If I forgot a closing tag, or something like that, an XML parser will tell me, and I can fix it. Even if a "tag soup parser" attacks it later, it will be more likely to do the right thing.
Yes, having a browser be able to tolerate errors is a good thing, as long as people continue to build things that aren't XHTML. The problem is, exactly which algorithm should a browser use to parse sloppy HTML? Different browsers will parse it in different ways.
And XML parsers are consistent enough, at this point, that if it doesn't break for you, it's not broken for anyone else. The whole reason for being flexible about what you receive is gone -- it's a bit like trying to tolerate broken ASCII (or Unicode).
XHTML isn't necessarily easier to parse than (valid) HTML.
Actually, it kind of is. You just fire an XML parser at it -- any XML parser -- and you have a DOM.
With HTML, you have to handle tons of quirks and cruft before you even get to the DOM -- where there's still plenty of quirks and cruft to handle before you attempt CSS...
Of course, it's not necessarily easier for browsers which don't support it, like IE, and... IE...
When they want to search for something, they "Google" it, the don't "Internet Explorer" it.
Which is exactly the point.
If they want to search for it, and it doesn't work, I imagine they'll assume something is wrong with their computer, or the Internet, or even their browser, if they know what that is.
And yes, Google.com has been down. And when this has happened, that was exactly the reaction.
They'll only understand that "I went to Google and it didn't work. What else can I use?"
No, they'll understand "I wanted to Google and it didn't work. How can I fix it?"
How they interpret "fix it" is up for debate. But I'm guessing Google is far, far more popular than IE right now.
Maybe the problem is that it's so easy to swap one search engine for another?
Consider: What if Myspace started doing that? How many people would actually drop Myspace for Facebook (who haven't already)?
Google is officially a verb. IE isn't.
Right. The appropriate place is onDocumentLoad, which is done by jQuery. I suppose there's still the possibility that a browser will show part of the document, while the rest is still loading...
The hack I've been doing, which isn't particularly friendly to non-Javascript users, is to disable elements I want to jQuery-ify, either with standard HTML form disabled attributes, or with display:none for links.
In other words, as everyone else gets more and more savvy, they get punished for their savviness by having to get around stupid measures?
For that reason, and many others, I say hell no.
Now, if you can make it easier for everyone else, without ruining it for savvy users, be my guest.
In the first place, if standards (HTML / CSS) had been designed right, we wouldn't need so many javascript workarounds.
Javascript isn't always a workaround -- it's a client-side programming language. That means you can, I don't know, write programs in it.
I don't think HTML or CSS need to be Turing-complete. I'd be a bit frightened if they were.
Excuse not to implement it: The user should decide!
I actually agree with this, but it's also a case where it's progressive enhancement. Leave the link target as something sane, and use a Javascript onClick handler.
Excuse not to implement it: SSI works just as well.
Bull.
Workaround: AJAX.
Which provides more than just this.
Granted, that's most of what people use it for, but it's far from the only possibility. Simplest thing I can think of is displaying how long ago a given event happened -- Javascript can update this dynamically, without having to hit the server at all.
Another example would be anything requiring live updates -- granted, it's a hack, but how would you implement a Comet-style push protocol in HTML/CSS? How would you implement a decent chat client without it?
I use Noscript and I don't even bother to explore sites that are totally borked without their Javascript crutch.
In other words, it doesn't even occur to you that Gmail might be useful.
Javascript is a tool. Like any tool, it can become a crutch, but it actually does provide things which are not possible -- and should never be possible -- with straight HTML/CSS.
It's a lovely ideal. But you code for IE or you learn to live on a diet of Ramen Noodles and Jolt Cola.
No, I code for IE when I'm being paid to.
But take intranet sites, or simple pseudo-desktop apps -- I can develop a web app about as well as I can a desktop GUI app, and then it's as cross-platform as the browser I target. Since people were expecting me to tell them to install some Visual Basic crap, it's not that big a deal to make them install Firefox.
The standard moves slowly as hell.
Which is an entirely moot point when the browsers move even slower, and IE is pretty much stalled.
It takes years to resolve real problems, because they're too busy with edge cases (XML namespaces mess!) to pump out specs that are useful.
Which is actually useful, when you're that particular edge case.
XQuery has NOTHING to do with browsers. Its an XML API like DOM and XSLT
Which some browsers support natively -- or am I thinking of xpath?
no one actually has a full implementation. Everyone is guessing.
That is one case I think the w3c went wrong -- no reference implementation. (Oh, there's Amaya, but let's be serious.) And the Acid tests are a great idea, but always lagging behind.
However, having exactly one implementation is not good, and should not be the basis for a standard -- unless that is an open source (probably public domain) and ridiculously well-tested, in the real world. The BSD network stack is a good example of that.
The CSS Zen Garden is an example of that. They start from the structure, and then do the best layout they can from that. If they start from a photoshop made by a designer, then try to apply it, its going to be another story.
That should tell you something about the usefulness of Photoshop as a web design tool.
http://code.google.com/p/android/downloads/list
Technically, Android is more locked down, yes.
Effectively, it's less. You can actually write any local, offline app you want, and distribute it pretty much any way you want. You don't have to code it in Java, you only have to target their pseudo-JVM.
Contrast to the iPhone -- yes, you can write native apps, and technically, you can do anything you want. But Apple has a truly massive list of restrictions, plus their own unpredictable whim, which determines whether or not you can run them.
So, in every way that counts, Android is looking less restrictive. If the only restriction is that your app runs somewhat slower, I really don't care. If they are placing restrictions on how you use the network, that's still an order of magnitude less restrictive than the iPhone.
Well, if any of them have a wifi port, it shouldn't be too hard to write some sort of package manager app for it which doesn't go through the Google store. Or just to pull apps directly from the Internet, or from your own machine.
Notice how you've chosen exactly which third party to trust with that kill switch -- and how you can easily bypass it, if needed.
Neither of which are true about Android, or the iPhone.
And you know what makes viruses profitable and successful?
Monoculture.
Did you have to open the case, or exploit the existing software at all?
It's the difference between installing Linux on a PC, and installing Linux on an Xbox.
Once all the reverse engineering is done, the PC requires that you put an Ubuntu DVD in it and follow the instructions. The Xbox requires various combinations of soldering, specific models of USB thumbdrives, owning a certain game, and avoiding a certain update.
That's what I mean by "lets". Does HTC just avoid helping? In that case, I'm not worried.
Or does HTC actively hinder, with things like trusted computing, DRM, etc? If Android phones do that, Android fails -- worse than the new MS "Open" XML.
Oh, and to answer your printer question:
http://www.linuxprinting.org/show_printer.cgi?recnum=Epson-Stylus_CX5400
http://www.linuxprinting.org/show_printer.cgi?recnum=Epson-Stylus_Photo_R1800
http://www.openprinting.org/printer_list.cgi?make=KONICA+MINOLTA
Epson and Minolta only support Windows and Mac OSX.
Bullshit:
http://www.linux.com/feature/113738
"The Epson America website directs you to Epson Kowa for Linux drivers for their printers, including one for the CX5400. You can download their GPLd binaries and source code from here."
The Mac OSX file system supports as big a file as anyone could buy a disk drive to hold it.
CIFS stands for Common Internet FileSystem. It's the new version of SMB. Without it, you indeed cannot read files bigger than 4 gigs from a Samba share, or from a shared folder on Windows.
What is the use of another file system for most users?
A fair question, but beside the point. You asked if there was software that wouldn't run on OS X, and there is.
And to answer that question, the use of another filesystem is if you have files stored on that other filesystem. If I need to recover files from a dead hard drive, I boot a Linux livecd, confident that it can read any filesystem I throw at it. Even if OS X had a livecd that would run on non-Mac hardware, it wouldn't be able to read either the XFS or the ext3 filesystem on this hard drive.
Who would want to use that when the GUI of OSX is far better?
Opinion, not fact. I like KDE, and I intensely dislike the OS X GUI.
Most free Mac software comes on DMG a disk image that opens and installs the software with a few mouse clicks.
Which is both unintuitive (tons of people just run them from the disk image, instead of dragging it to applications) and not a package manager.
Dependencies, reverse-dependencies, automatic updates (or manual updates of the entire system with a single click/command), actual uninstallation (do I drag it to the trash? Do I find the .mpkg?), huge repositories of known-good software (as in, not malicious), trivially scriptable for setting up a new, custom installation exactly the way you want, without resorting to disk images.
You could argue that none of the above things are needed -- which would be kind of like claiming none of the advanced features of Photoshop are really needed, and we should all be content with the Gimp. If your main argument is that features aren't needed, you've already lost.
I happen to like those features. In particular, there's no way in hell I'm going back to checking each of 10 or 20 free Mac programs for updates manually, by going to the website.
I loved Enterprise for being the one Star Trek where they couldn't fall back on the Prime Directive as an excuse to never actually make a political statement.
Unfortunately, it also had that other thing I hate so much about Trek -- all the temporal plots. Yawn!
I'm really not sure what your comment about AJAX calls has to do with "ignoring standards" -- especially given that:
- XMLHttpRequest is a standard
- It was always possible with a hidden iframe anyway, which is also a standard