While I agree that for many usage patterns, 100Mb/s is more than enough, this is not true for everybody.
As for 11Mb/s (802.11b) being sufficient - that's probably true if you're using your LAN for basic 'Net access, synching documents between machines, sharing small files, etc - but rapidly falls down under any greater loads. For one, you're on a shared medium - and _4_ 802.11b clients starts to suck in a hurry. Many things do see large improvements when run over faster networks than basic WiFi, too. I find this particularly noticeable with remote X applications (which I use a lot) and huge print jobs.
I also do a lot of work with disk images. When you're lobbing 20GB images around a lot, you start to enjoy gigabit ethernet. While it's true that disks are almost always incapable of meeting the full demands of a gigabit link, they ARE capable of going faster than 100Mb/s. As such, I see a huge improvement with gigabit.
Additionally, disk issues depend on the workload. A basic IDE or SATA disk will miserably fail to cope with 10 concurrent random read/write threads - I've seen them fall below 10 MB/s. On the other hand, a decent SCSI disk or a good SATA disk with TCQ will often cope very well. A good OS helps a lot, too.
On the flip side, my bog-standard Western Digital and Maxtor 7200RPM 120GB disks can easily chuck 40MB/s over the wire in single-client streaming reads - the Maxtor sometimes clocks 50MB/s. When imaging a machine, this is very nice indeed.
So... while you don't need gigabit ethernet, others may - and it can work very well indeed.
I don't think they would be open to false advertising claims, no. Not if they just said "Gigabit Ethernet" - which is when it comes down to it merely a name for a standard. If they said "Capable of full gigabit-per-second speeds" then I expect the false advertising claim/might/ have a chance... but I doubt it.
After all, if a 400Mb/s "gigabit" switch is false advertising, then "108Mb/s" WiFi would be <i>doomed</i>. What a pleasant thought. "108mb/s, when running in full duplex with full utilisation of both directions, in lab conditions, including all link-layer overheads, without encryption, maybe." By those idiot's logic, 1000baseTX would be "Two Gigabit Ethernet!". Show me two-gigabit throughput in normal usage situations, and I'll care.
You can IPv6-enable your network(s) now, using the global 6to4 address space. With a 6to4 gateway you can talk to other 6to4 hosts using transparent tunneling over ipv4, without the ipv6 hosts being aware of it. Any recent Linux or BSD should have support for acting as a 6to4 gateway.
With a relatively recent setup, you should find that your default route to the 'real' ipv6 internet is 192.88.99.1, a multicast address that finds the nearest 6to4-to-native gateway. My IPv6 internal hosts can talk to the native IPv6 without my having to do any manual configuration of the gateway or client hosts. As closer sites are IPv6 enabled, the choice of relay router gets closer, with no configuration by you.
So... IPv6 enable your networks now, so that we can get rid of this stupid chicken-and-egg 'no demand'/'no supply' argument. There _is_ supply, thanks to 6to4, so lets use it now and encourage upstream providers to adopt IPv6 so we can start seeing more of the benefits.
As it is, I no longer need to worry about NAT when talking to internal hosts on any of the networks I operate - it's transparent and easy:
I also love the lack of DHCP in IPv6 (addresses are calculated by hosts using data broadcast by IPv6 routers, + their MAC address) and it's general ability to intelligently auto-configure things.
Indeed. I think you missed another important one, though: Not all sex is "adult" material. There is important educational material, and general life information, that should _not_ be forced into some special list of 'restricted sites'. Not unless you _like_ your teenagers pregnant and saying "umm... what's happening? I thought babies came from storks."
<rant> Many people outside America are disturbed by the way that things like violent 'police watch' shows, and other often extremely violent content, is considered par for the course, while anything vaguely smacking of sex is screamed about unendingly. The ridiculous and almost unending coverage of a certain recent sporting event is a good example - I mean, WTF?!? </rant>
That's an acceptable (and reasonable) solution when writing on the 'net, or developing user interfaces, and one I tend to forget about because of the common prevalence these days of 'shorthand' dates as the standard.
It doesn't solve the lexical sorting issue, though - you still need ISO dates for that purpose.
ISO dates are the way to go - for the sanity of everybody concerned. They sort lexically in a sensible way, they're in a reasonable order, and they're unambiguous (YYYY- not YY-).
This, of course, is why nobody uses them.
*sigh*
As the evil dictator-like sysadmin, at work all my in-house intranet tools report ISO dates. I had a few people confused at first, but now it's the accepted format at work for things like archive directories (hundreds of directories named NN-NN-NN, NN.NN.NN or NNNNNN can get rather confusing - YYYY-MM-DD is so much easier).
Now, if only the/rest/ of the world would change over.
While we're at it, can we have the ISO paper sizes adopted by the few holdouts, too? (I only wish...)
Finially, they're biting the bullet and doing the right thing. A sensibly configured default firewall - it's one of the things they should've been doing for years. The memory protection is also interesting - and probably a good move, so long as developers don't start using it as a crutch.
Now, if we see built-in virus protection, tainting or sandboxing of executable code recieved by email, proper MIME handling, and flagging of double extensions, AND AUTOMATIC UPDATES THAT ARE ON BY DEFAULT, it'll be mostly there.
Even forcing users to take an extra step (like the 'chmod u+x' required on *NIX) to make emailed and downloaded files executable would help a _lot_. Sure, viri would just start saying "click properties, then tick 'executable'" in the messages; but it'd stop a lot of the worst offenders from viewing things without thinking.
Well, of all OEMS. If you've ever dealt with HP, Dell, etc on a personal level (not company2company) it's awful - I'm not surprised. Their "support" is there to deny fault, get you off the phone, or otherwise get rid of you. I've had an HP that was faulty on arrival, and been stalled by support until the 30day replacement guarantee is over - whereupon they say I have to ship it to their repair facility (in Queensland). They don't support it with any 3rd party software on it - _any_. Like, say, memtest86. Windows didn't crash - much - but it coudln't run/anything/ else properly. "Sorry, we don't support...."
Yeah, I think you got it in one when you said:
So if Apple's support is "horrible", then I guess everyone else is a lot worse
Deal with a good local white-box place, then tell me Apple are good. My local place has loaned me a PC when mine died; swapped a HDD for me in advance so I can image the data across, etc. Let's see any OEM match that sort of service. Of course, I'm a long-time customer of theirs and they're well above average - I know most white-box places are totally crap as well.
Also, unless you buy an extended warranty Apple are f**ing useless. Even within your (brief) free phone support period, they're always trying to sell you AppleCare instead of helping you fix the problem. I already paid a large premimum for the hardware, and find the poor support offensive. I run a production network of Macs at work, and there's little I dislike more than calling Apple's support (namely, calling Quark or Xerox support).
I'm an _ex_ mac user, of course, so write me off as biased if you like. I just got tired of the hardware pricing, the more-expensive-than-WinXP OS, the quirks ("No, you can't have an eject button for your CD-ROM. Oh, and Macs don't crash, so we've removed the reset switch.") Alternately, maybe I have experience dealing with many different people and loathe all Apple and all other OEMs for a reason.
I must confess to finding Apple a special case. I'd say they have a perpertual case of "almost excellent" - OSX being a great example. A great idea, well done... but with the classic MacOS quirkiness ("nope; I don't feel like doing that today"). Painful little oversights - like the ability to burn CDs in ISO9660 or HFS, but only HFS support for burning DVDs - WTF?!? Removing the reset button from recent hardware - and the reason I was given by Apple support was, in fact, because "it's no longer needed with MacOS X." *lol*
At least the other OEMs are honestly just crap in every regard - you know what you're getting. And, ideally, not to buy it in the first place.
Craig Ringer
That's more a result of the apps than the language
on
Rexx for Everyone
·
· Score: 1
AppleScript on MacOS has a similar advantage. Alas, for some reason application-scripting languages (PL/SQL, REXX, AppleScript...) always seem to be the somewhat (or, in AppleTalk's case,/really/) icky ones.
I'd dearly love to see a common application scripting interface that was language independent. DCOP under KDE is nice, but we really need something universal. Ideally cross-platform, but with the entranched VB+COM/DCOM under Win32 and AppleScript under OSX, this seems unlikely.
(may not display properly - whatever, you get the picture)
and getting a perfectly valid ssl session. With entirely the wrong people - but the user would only notice if they looked at the cert.
Of course, you'd have to find a cert registrar dumb or unethical enough to give you a cert for the domain, but with people like Verisign around that can't be hard.
and yeah, Xinerama is an issue. I hadn't noticed any dpi overrides though - at least with GDM2 or the KDM from KDE3.1, plus a modern (4.3) XFree86 the dpi seems to be maintained as one would expect.
I find it's generally pretty good about grabbing the physical dimensions from the monitor using DDC, so on good quality monitors and video cards XFree86 should just figure it out.
Alas, this is not true in many hardware combinations, older versions of Xservers, or other OSes.
And yeah - windows does break horribly when one tweaks the DPI. Especially since it's apparently incapable of fetching it from the hardware:-( and there are too many stupid programmers out there.
I think the varying fonts, toolkits, themes and configuratons you find on Linux are a major advantage there - apps must be able to work well with a wide variety of fonts and sizes. As a result, one of the staff at work who is partly blind really likes her LTSP box - I've set the fonts to "bloody massive" (something like 5x size) and it's still quite useable. Windows broke down horribly above 125%.
Also, setting type to (say) 4mm doesn't help people with visual problems. You're forcing them to lie to their OS about their screen dpi or override your font settings in their client just to get readable text. Relative measures respect the user's preferences, and are more compatable.
Indeed. Unfortunately, most OSes out there treat '1pt' as a certain number of pixels, instead of trying to make sure that 1pt is the right size. Some can be told the resolution of the output device, and will scale the measure appropriately - but most current OSes either don't support higher-dpi displays properly or must be manually configured to support them. As a result, the use of 'pt' in web design isn't really practical, and won't be until OS designers pull out their thumbs.
I suspect that MacOS X may get measures like 'pt' right. Most XFree86 systems attached to a _modern_ video card and monitor, if the monitor correctly reports it's physical dimensions using DDC, will get it partly right. I don't know about WinXP, but win2k/98/etc don't appear to correctly support high-res displays (at least in the interface or IE), nor does MacOS 7/8/9. That's far too many people.
My personal system (Linux/XFree86) behaves partly as you describe - at higher resolutions, type isn't smaller, just smoother and more detailed. The rest of the UI is just smaller, however, due to limitations in the current rendering system. It would be possible to do this under Windows, but increasing the font sizes globally tends to mangle a lot of apps UIs, as they assume for layout purposes that '12pt=16px' or whatever. I believe MacOS X may scale all UI elements properly, but I've only used it briefly so I can't really remember. Cairo, a new display-PostScript-like based rendering system for XFree86, should make this possible under *NIX. Maybe Longhorn will do it for Windows, but you can't expect that to be deployed widely for a while.
Because of these issues, I suggest simply avoiding the use of the 'pt' measure in web design (I use it in media-specific stylesheets for print, but never for general display). Yeah, I know it's a broken client problem - but practicality must take precedence here.
That's fair - but as you said yourself it's not practical at present. Perhaps once DVI LCDs are universal, since they actually do proper reporting of screen dpi. For the next 5 years or so we're going to have to avoid using pt because of broken clients and broken OSes.
Re:font comments - email to admins
on
Web 'Rules' Changing?
·
· Score: 2, Insightful
I don't think alternate style sheets should be needed to view a page. _Especially_ for someone who has more trouble than most using a computer at all. They're fine for extra features or browser-specific funkyness, but I don't think you should need them. Among other things many browsers don't support them. Ditto user CSS - nobody should have to know how to use it, and set it up, just to be able to use the 'net.
You can not safely assume that all users have Couter, Arial, and Times New Roman. 'serif' and 'sans-serif' should always be used as fallbacks. In reality most OSes and browsers (via CSS) remap those names to valid font names if they don't have the exact fonts, but the font metrics may not be exactly the same. In other words, it'll be fine so long as you're not doing exact char postitioning or relying on the lines being exactly x high. You shouldn't be doing that anyway IMHO.
I actually avoid using explicit font names, because I think the user's preferences in their browser should be respected. I'll use explicit fonts for headings/headlines, nav, etc, but body text and the other "major" content is left to the client unless I have some good reason to do otherwise.
Personally, I spend quite a bit of time cursing the f**ers responsible for the ie5/6 CSS code, and the netscape 4 alleged-CSS code.
I just fired this off to the admins of the site: ----
Hi folks
I have a few comments about your useability guidelines, most notably the font recommendations found at http://usability.gov/guidelines/fonts.html.
While I agree that a 10pt font is ideal for many people, I think it's totally inappropriate for a website to ever set this. Many people are using high resolution or high-DPI screens where 10pt is unreadable; many need larger fonts because of visual impairment; some may want smaller text, etc. Setting an explicit point size will override any preferences the user may have made in their client.
I have visually impaired users at work, and they find many websites apalling - I've had to set their browsers to ignore the website's font settings to make many sites useable. This is not a good situation for anybody, as the site designer uses font size and face as a significant cue for navigation and reading.
As such, I'd love to see you note on your useability guidelines that font sizes should only be set uding relative properties - the 'em' measure in CSS, the '%' measure in CSS, the 'larger'/'smaller' descriptive terms of CSS or the 'SIZE="+-n"' measures in the HTML <FONT> tag. CSS 'pt' or 'px' should never be used where accessability is a concern.
For an illustration of this problem, I suggest that you find a computer with a 19" monitor capable of at least 1600x1200 (or a 21" that can do 2048x1536) and try to use sites that are set to 10pt. Ideally find someone a bit older for this test. For even more fun, use an OS other than Windows that is not guaranteed to have access to the specific fonts the website designer previewed their site using.
Another issue I think well worth mentioning is the use of leading/kerning controls in CSS, especially combined with the use of absolute measurements. Setting the leading in type may well make things look very 'crisp' and 'professional' on the designer's screen, but often makes the content almost unreadable for people who don't have the same fonts, use large or small type, or otherwise differ from the configuration of the designer's test systems. Leading specified in 'px' or 'pt' is especially bad, as this causes each line of type to overlap when the font size is larger than that the page was designed for; it also causes lines to space out very annoyingly when using smaller type sizes. If leading must be specified, it should be expressed in relative measures like 'em' or percent, so that the leading scales with the type size.
One final comment: some sites, while designed to work with a range of type sizes, fall down severely when viewed with _extremely_ large type as is needed for someone who is partly blind. One of the staff at work has serious vision problems, and she finds that on many sites the columns do not expand with the type. If the type is large enough that only one word fits in each column, this is hard to read - but as words aren't broken, if the columns are a little narrower than type can overlap. This makes a site unuseable. Again, it's easily fixed - column and table sizes should be specified in relative measures such as 'em' or percent, never in pixels or point sizes.
Unfortunately, certain buggy web browsers - such as many versions of Microsoft Internet Explorer - have severly broken CSS implementations that make this more difficult than it should be. It is still possible to design good sites that work well even for people who need or prefer different type sizes, however - and I think this is an important thing to encourage.
As monitor resolutions get higher and computer use even more universal, this will no doubt become more of an issue.
I'd love to hear your comments on these suggestions.
Company slowly falling in value as it's products become more and more irrelevant in the market, until it suddenly announces that it owns the up-and-coming player and starts pumping the press.
Sure, you could've made quite a bit of money off SCO. You also run the risk of them being forced into honest and complete discovery while holding shares, whereupon you're unlikely to be left holding much.
By price, I would call the current macs "workstations" rather more than desktop PCs. I'm sitting at a dual Xeon box that cost less than a mid-range G5, and I wouldn't call that a "PC" any more than I would a G5.
DVDs: can't copy them, can't fast-forward through ads
Huh? Region coding... hmm, I heard about that once.
I hire Region 1 DVDs quite frequently, despite being in Australia - and often only notice after watching it. A quick RPC-1 patch to the DVD-ROM's firmware, plus a/decent/ DVD player, and all is happy.
The point is that as the lockdown gets more offensive, more people will just ignore it. These schemes will always be broken, and eventually broken in ways that can't be fixed while retaining backward compatability. It's irritating, and many people don't/can't ignore the restrictions, but it's not the end of the world.
I still think it's revolting, counterproductive, annoying, and generally offensive though.
From chilling effects, the letter there is nothing in the memo claiming that the documents have been altered, claims of liebel, etc. They simply claim that the site links to documents to which Diebold holds the copyright that are being published without Diebold's consent. You'd think they'd take that approach instead of claiming that they own the documents being published if they thought they could.
For that matter, though, have they even registered a copyright on these documents? Can they sue for copyright infringement if they haven't explicity registered a copyright? I don't know what the law is - in the USA or here in Australia for that matter - but I'd be interested to find out.
By DMCAing people who host or link to these documents, they're implicity confirming their validity. I almost wonder if a "deny everything" policy might've worked better for them:
"Nope, never seen those before. Guess somebody thinks it's funny to try to discredit a reliable, trustworthy company like us."
Insead, they've chosen "arrgggh, give those back! You can't show people those - they're secret!". Hmm...
Slashdot Mirror
[note: Mb = Megabit, MB = megabyte]
... while you don't need gigabit ethernet, others may - and it can work very well indeed.
While I agree that for many usage patterns, 100Mb/s is more than enough, this is not true for everybody.
As for 11Mb/s (802.11b) being sufficient - that's probably true if you're using your LAN for basic 'Net access, synching documents between machines, sharing small files, etc - but rapidly falls down under any greater loads. For one, you're on a shared medium - and _4_ 802.11b clients starts to suck in a hurry. Many things do see large improvements when run over faster networks than basic WiFi, too. I find this particularly noticeable with remote X applications (which I use a lot) and huge print jobs.
I also do a lot of work with disk images. When you're lobbing 20GB images around a lot, you start to enjoy gigabit ethernet. While it's true that disks are almost always incapable of meeting the full demands of a gigabit link, they ARE capable of going faster than 100Mb/s. As such, I see a huge improvement with gigabit.
Additionally, disk issues depend on the workload. A basic IDE or SATA disk will miserably fail to cope with 10 concurrent random read/write threads - I've seen them fall below 10 MB/s. On the other hand, a decent SCSI disk or a good SATA disk with TCQ will often cope very well. A good OS helps a lot, too.
On the flip side, my bog-standard Western Digital and Maxtor 7200RPM 120GB disks can easily chuck 40MB/s over the wire in single-client streaming reads - the Maxtor sometimes clocks 50MB/s. When imaging a machine, this is very nice indeed.
So
I don't think they would be open to false advertising claims, no. Not if they just said "Gigabit Ethernet" - which is when it comes down to it merely a name for a standard. If they said "Capable of full gigabit-per-second speeds" then I expect the false advertising claim /might/ have a chance ... but I doubt it.
After all, if a 400Mb/s "gigabit" switch is false advertising, then "108Mb/s" WiFi would be <i>doomed</i>. What a pleasant thought. "108mb/s, when running in full duplex with full utilisation of both directions, in lab conditions, including all link-layer overheads, without encryption, maybe." By those idiot's logic, 1000baseTX would be "Two Gigabit Ethernet!". Show me two-gigabit throughput in normal usage situations, and I'll care.
You can IPv6-enable your network(s) now, using the global 6to4 address space. With a 6to4 gateway you can talk to other 6to4 hosts using transparent tunneling over ipv4, without the ipv6 hosts being aware of it. Any recent Linux or BSD should have support for acting as a 6to4 gateway.
... IPv6 enable your networks now, so that we can get rid of this stupid chicken-and-egg 'no demand'/'no supply' argument. There _is_ supply, thanks to 6to4, so lets use it now and encourage upstream providers to adopt IPv6 so we can start seeing more of the benefits.
With a relatively recent setup, you should find that your default route to the 'real' ipv6 internet is 192.88.99.1, a multicast address that finds the nearest 6to4-to-native gateway. My IPv6 internal hosts can talk to the native IPv6 without my having to do any manual configuration of the gateway or client hosts. As closer sites are IPv6 enabled, the choice of relay router gets closer, with no configuration by you.
So
As it is, I no longer need to worry about NAT when talking to internal hosts on any of the networks I operate - it's transparent and easy:
internalhost_net1$ ssh -6 internalhost_net2
internalhost_net2$
I also love the lack of DHCP in IPv6 (addresses are calculated by hosts using data broadcast by IPv6 routers, + their MAC address) and it's general ability to intelligently auto-configure things.
Not all "adult" material is sex
Indeed. I think you missed another important one, though: Not all sex is "adult" material. There is important educational material, and general life information, that should _not_ be forced into some special list of 'restricted sites'. Not unless you _like_ your teenagers pregnant and saying "umm... what's happening? I thought babies came from storks."
<rant>
Many people outside America are disturbed by the way that things like violent 'police watch' shows, and other often extremely violent content, is considered par for the course, while anything vaguely smacking of sex is screamed about unendingly. The ridiculous and almost unending coverage of a certain recent sporting event is a good example - I mean, WTF?!?
</rant>
That's an acceptable (and reasonable) solution when writing on the 'net, or developing user interfaces, and one I tend to forget about because of the common prevalence these days of 'shorthand' dates as the standard.
It doesn't solve the lexical sorting issue, though - you still need ISO dates for that purpose.
ISO dates are the way to go - for the sanity of everybody concerned. They sort lexically in a sensible way, they're in a reasonable order, and they're unambiguous (YYYY- not YY-).
/rest/ of the world would change over.
This, of course, is why nobody uses them.
*sigh*
As the evil dictator-like sysadmin, at work all my in-house intranet tools report ISO dates. I had a few people confused at first, but now it's the accepted format at work for things like archive directories (hundreds of directories named NN-NN-NN, NN.NN.NN or NNNNNN can get rather confusing - YYYY-MM-DD is so much easier).
Now, if only the
While we're at it, can we have the ISO paper sizes adopted by the few holdouts, too? (I only wish...)
They were turned on in SP1, then, yes?
Finially, they're biting the bullet and doing the right thing. A sensibly configured default firewall - it's one of the things they should've been doing for years. The memory protection is also interesting - and probably a good move, so long as developers don't start using it as a crutch.
Now, if we see built-in virus protection, tainting or sandboxing of executable code recieved by email, proper MIME handling, and flagging of double extensions, AND AUTOMATIC UPDATES THAT ARE ON BY DEFAULT, it'll be mostly there.
Even forcing users to take an extra step (like the 'chmod u+x' required on *NIX) to make emailed and downloaded files executable would help a _lot_. Sure, viri would just start saying "click properties, then tick 'executable'" in the messages; but it'd stop a lot of the worst offenders from viewing things without thinking.
Well, of all OEMS. If you've ever dealt with HP, Dell, etc on a personal level (not company2company) it's awful - I'm not surprised. Their "support" is there to deny fault, get you off the phone, or otherwise get rid of you. I've had an HP that was faulty on arrival, and been stalled by support until the 30day replacement guarantee is over - whereupon they say I have to ship it to their repair facility (in Queensland). They don't support it with any 3rd party software on it - _any_. Like, say, memtest86. Windows didn't crash - much - but it coudln't run
Yeah, I think you got it in one when you said:
Deal with a good local white-box place, then tell me Apple are good. My local place has loaned me a PC when mine died; swapped a HDD for me in advance so I can image the data across, etc. Let's see any OEM match that sort of service. Of course, I'm a long-time customer of theirs and they're well above average - I know most white-box places are totally crap as well.
Also, unless you buy an extended warranty Apple are f**ing useless. Even within your (brief) free phone support period, they're always trying to sell you AppleCare instead of helping you fix the problem. I already paid a large premimum for the hardware, and find the poor support offensive. I run a production network of Macs at work, and there's little I dislike more than calling Apple's support (namely, calling Quark or Xerox support).
I'm an _ex_ mac user, of course, so write me off as biased if you like. I just got tired of the hardware pricing, the more-expensive-than-WinXP OS, the quirks ("No, you can't have an eject button for your CD-ROM. Oh, and Macs don't crash, so we've removed the reset switch.") Alternately, maybe I have experience dealing with many different people and loathe all Apple and all other OEMs for a reason.
I must confess to finding Apple a special case. I'd say they have a perpertual case of "almost excellent" - OSX being a great example. A great idea, well done
At least the other OEMs are honestly just crap in every regard - you know what you're getting. And, ideally, not to buy it in the first place.
Craig Ringer
AppleScript on MacOS has a similar advantage. Alas, for some reason application-scripting languages (PL/SQL, REXX, AppleScript...) always seem to be the somewhat (or, in AppleTalk's case, /really/) icky ones.
I'd dearly love to see a common application scripting interface that was language independent. DCOP under KDE is nice, but we really need something universal. Ideally cross-platform, but with the entranched VB+COM/DCOM under Win32 and AppleScript under OSX, this seems unlikely.
It's the one thing I miss about MacOS.
Just imagine going to:
a u/
https://ϲоmmоnwealthbank.com.
(may not display properly - whatever, you get the picture)
and getting a perfectly valid ssl session. With entirely the wrong people - but the user would only notice if they looked at the cert.
Of course, you'd have to find a cert registrar dumb or unethical enough to give you a cert for the domain, but with people like Verisign around that can't be hard.
Because then some bugger would just get you with a few "interesting" terminal escapes, just like the old days.
...
OK, so it's not exactly _likely_
Just think what fun you could have with cache poisoning.
and yeah, Xinerama is an issue. I hadn't noticed any dpi overrides though - at least with GDM2 or the KDM from KDE3.1, plus a modern (4.3) XFree86 the dpi seems to be maintained as one would expect.
:-( and there are too many stupid programmers out there.
I find it's generally pretty good about grabbing the physical dimensions from the monitor using DDC, so on good quality monitors and video cards XFree86 should just figure it out.
Alas, this is not true in many hardware combinations, older versions of Xservers, or other OSes.
And yeah - windows does break horribly when one tweaks the DPI. Especially since it's apparently incapable of fetching it from the hardware
I think the varying fonts, toolkits, themes and configuratons you find on Linux are a major advantage there - apps must be able to work well with a wide variety of fonts and sizes. As a result, one of the staff at work who is partly blind really likes her LTSP box - I've set the fonts to "bloody massive" (something like 5x size) and it's still quite useable. Windows broke down horribly above 125%.
Also, setting type to (say) 4mm doesn't help people with visual problems. You're forcing them to lie to their OS about their screen dpi or override your font settings in their client just to get readable text. Relative measures respect the user's preferences, and are more compatable.
Craig Ringer
then it's probably not ever going to get set on 90% of the systems out there. Alas.
Indeed. Unfortunately, most OSes out there treat '1pt' as a certain number of pixels, instead of trying to make sure that 1pt is the right size. Some can be told the resolution of the output device, and will scale the measure appropriately - but most current OSes either don't support higher-dpi displays properly or must be manually configured to support them. As a result, the use of 'pt' in web design isn't really practical, and won't be until OS designers pull out their thumbs.
I suspect that MacOS X may get measures like 'pt' right. Most XFree86 systems attached to a _modern_ video card and monitor, if the monitor correctly reports it's physical dimensions using DDC, will get it partly right. I don't know about WinXP, but win2k/98/etc don't appear to correctly support high-res displays (at least in the interface or IE), nor does MacOS 7/8/9. That's far too many people.
My personal system (Linux/XFree86) behaves partly as you describe - at higher resolutions, type isn't smaller, just smoother and more detailed. The rest of the UI is just smaller, however, due to limitations in the current rendering system. It would be possible to do this under Windows, but increasing the font sizes globally tends to mangle a lot of apps UIs, as they assume for layout purposes that '12pt=16px' or whatever. I believe MacOS X may scale all UI elements properly, but I've only used it briefly so I can't really remember. Cairo, a new display-PostScript-like based rendering system for XFree86, should make this possible under *NIX. Maybe Longhorn will do it for Windows, but you can't expect that to be deployed widely for a while.
Because of these issues, I suggest simply avoiding the use of the 'pt' measure in web design (I use it in media-specific stylesheets for print, but never for general display). Yeah, I know it's a broken client problem - but practicality must take precedence here.
That's fair - but as you said yourself it's not practical at present. Perhaps once DVI LCDs are universal, since they actually do proper reporting of screen dpi. For the next 5 years or so we're going to have to avoid using pt because of broken clients and broken OSes.
I don't think alternate style sheets should be needed to view a page. _Especially_ for someone who has more trouble than most using a computer at all. They're fine for extra features or browser-specific funkyness, but I don't think you should need them. Among other things many browsers don't support them. Ditto user CSS - nobody should have to know how to use it, and set it up, just to be able to use the 'net.
You can not safely assume that all users have Couter, Arial, and Times New Roman. 'serif' and 'sans-serif' should always be used as fallbacks. In reality most OSes and browsers (via CSS) remap those names to valid font names if they don't have the exact fonts, but the font metrics may not be exactly the same. In other words, it'll be fine so long as you're not doing exact char postitioning or relying on the lines being exactly x high. You shouldn't be doing that anyway IMHO.
I actually avoid using explicit font names, because I think the user's preferences in their browser should be respected. I'll use explicit fonts for headings/headlines, nav, etc, but body text and the other "major" content is left to the client unless I have some good reason to do otherwise.
Personally, I spend quite a bit of time cursing the f**ers responsible for the ie5/6 CSS code, and the netscape 4 alleged-CSS code.
I just fired this off to the admins of the site:
.
----
Hi folks
I have a few comments about your useability guidelines, most notably the font recommendations found at http://usability.gov/guidelines/fonts.html
While I agree that a 10pt font is ideal for many people, I think it's totally inappropriate for a website to ever set this. Many people are using high resolution or high-DPI screens where 10pt is unreadable; many need larger fonts because of visual impairment; some may want smaller text, etc. Setting an explicit point size will override any preferences the user may have made in their client.
I have visually impaired users at work, and they find many websites apalling - I've had to set their browsers to ignore the website's font settings to make many sites useable. This is not a good situation for anybody, as the site designer uses font size and face as a significant cue for navigation and reading.
As such, I'd love to see you note on your useability guidelines that font sizes should only be set uding relative properties - the 'em' measure in CSS, the '%' measure in CSS, the 'larger'/'smaller' descriptive terms of CSS or the 'SIZE="+-n"' measures in the HTML <FONT> tag. CSS 'pt' or 'px' should never be used where accessability is a concern.
For an illustration of this problem, I suggest that you find a computer with a 19" monitor capable of at least 1600x1200 (or a 21" that can do 2048x1536) and try to use sites that are set to 10pt. Ideally find someone a bit older for this test. For even more fun, use an OS other than Windows that is not guaranteed to have access to the specific fonts the website designer previewed their site using.
Another issue I think well worth mentioning is the use of leading/kerning controls in CSS, especially combined with the use of absolute measurements. Setting the leading in type may well make things look very 'crisp' and 'professional' on the designer's screen, but often makes the content almost unreadable for people who don't have the same fonts, use large or small type, or otherwise differ from the configuration of the designer's test systems. Leading specified in 'px' or 'pt' is especially bad, as this causes each line of type to overlap when the font size is larger than that the page was designed for; it also causes lines to space out very annoyingly when using smaller type sizes. If leading must be specified, it should be expressed in relative measures like 'em' or percent, so that the leading scales with the type size.
One final comment: some sites, while designed to work with a range of type sizes, fall down severely when viewed with _extremely_ large type as is needed for someone who is partly blind. One of the staff at work has serious vision problems, and she finds that on many sites the columns do not expand with the type. If the type is large enough that only one word fits in each column, this is hard to read - but as words aren't broken, if the columns are a little narrower than type can overlap. This makes a site unuseable. Again, it's easily fixed - column and table sizes should be specified in relative measures such as 'em' or percent, never in pixels or point sizes.
Unfortunately, certain buggy web browsers - such as many versions of Microsoft Internet Explorer - have severly broken CSS implementations that make this more difficult than it should be. It is still possible to design good sites that work well even for people who need or prefer different type sizes, however - and I think this is an important thing to encourage.
As monitor resolutions get higher and computer use even more universal, this will no doubt become more of an issue.
I'd love to hear your comments on these suggestions.
Craig Ringer
http://finance.yahoo.com/q/bc?s=SCOX&t=5y&l=on&z=m &q=l&c=
Company slowly falling in value as it's products become more and more irrelevant in the market, until it suddenly announces that it owns the up-and-coming player and starts pumping the press.
Sure, you could've made quite a bit of money off SCO. You also run the risk of them being forced into honest and complete discovery while holding shares, whereupon you're unlikely to be left holding much.
By price, I would call the current macs "workstations" rather more than desktop PCs. I'm sitting at a dual Xeon box that cost less than a mid-range G5, and I wouldn't call that a "PC" any more than I would a G5.
I tend to agree with the reviewers.
Craig Ringer
DVDs: can't copy them, can't fast-forward through ads
/decent/ DVD player, and all is happy.
Huh? Region coding... hmm, I heard about that once.
I hire Region 1 DVDs quite frequently, despite being in Australia - and often only notice after watching it. A quick RPC-1 patch to the DVD-ROM's firmware, plus a
The point is that as the lockdown gets more offensive, more people will just ignore it. These schemes will always be broken, and eventually broken in ways that can't be fixed while retaining backward compatability. It's irritating, and many people don't/can't ignore the restrictions, but it's not the end of the world.
I still think it's revolting, counterproductive, annoying, and generally offensive though.
From chilling effects, the letter there is nothing in the memo claiming that the documents have been altered, claims of liebel, etc. They simply claim that the site links to documents to which Diebold holds the copyright that are being published without Diebold's consent. You'd think they'd take that approach instead of claiming that they own the documents being published if they thought they could. For that matter, though, have they even registered a copyright on these documents? Can they sue for copyright infringement if they haven't explicity registered a copyright? I don't know what the law is - in the USA or here in Australia for that matter - but I'd be interested to find out.
By DMCAing people who host or link to these documents, they're implicity confirming their validity. I almost wonder if a "deny everything" policy might've worked better for them:
"Nope, never seen those before. Guess somebody thinks it's funny to try to discredit a reliable, trustworthy company like us."
Insead, they've chosen "arrgggh, give those back! You can't show people those - they're secret!". Hmm...