Re:alas, not 0.9.5
on
Netscape 6.2
·
· Score: 5, Informative
Use Mozilla 0.95 and you will see the wonders of the <link> tag;-)
Basically, they're a way for a web page author to specify related pages in a browser-independent, design-independent, extensible way, outside the main HTML of a page - think of them as "quick links" whose targets are defined by the page you're on. A long multi-page document might define Next, Previous and Contents to go to the obvious places, for instance. A website with content from many authors might define the Authors link so it goes to a list of this document's authors. A site with a specific copyright policy might link to it with the Copyright link. All of these are independent of the actual text in the HTML (they go in the <head> section) so if your browser doesn't support them, or you configure it not to, you'll never see them.
The W3C defined the meanings of quite a few links, and the Mozilla developers have added a couple more which they felt should be there for symmetry (W3C defined First, but not Last; Mozilla looks for Last too, for symmetry, and the Mozilla team have given the W3C a very short list of extras like Last which they think should go in the next HTML spec). You can use anything you like, though (Mozilla implements this by putting any unknown ones in a submenu).
Mozilla shows the <link>s as an extra toolbar, but there are other ways you could display them.
The defined ones are things like Previous, Next, First, Up, Top, Help, Authors, Search and Copyright - the sort of things many web pages and documents want. (At the moment Slashdot uses Top and Search).
Re:Netscape? no thanks.
on
Netscape 6.2
·
· Score: 2, Interesting
Mozilla *is* made by Netscape. Yes, it's open-source, but most of the major contributors are Netscape employees who're paid to work on it. They then do an occasional code freeze, fix the most obvious bugs in the frozen version, add horrible branding, and call it Netscape 6.
The Gecko engine (Mozilla's renderer) has the advantage that, unlike NS4, it makes an effort to render non-legacy HTML correctly. Ever tried persuading Netscape 4 to work with perfectly correct Cascading Stylesheets? (Yes, I even tried running the W3C validator on them. They *were* valid.) It supports just enough CSS to try to parse the stylesheet, but not enough to get it right (overlapping images and text were a common problem for me). At the moment my website uses a loading method which *should* be supported, and is supported by everything else which uses CSS (IE, Mozilla/NS6, Opera,...), specifically to trick NS4 into rendering the no-CSS simple-but-legible version instead of its broken half-CSS.
And that's quite impressive considering that
"Cascading Style Sheets, level 1 (CSS1) became a W3C Recommendation in December 1996."
-- w3.org
Having access to all the capabilities of your 2D monitor is a good thing too. Since your monitor displays in 2D and you basically see in 2D (assume your eyes are close together:-) this seems like an optimal number of dimensions to be using. "3D" games and OSs are limited to rendering 3D objects onto a 2D screen, but even if you had some sort of holodeck or something, where all 3 dimensions are rendered, you'd only see 2 at a time anyway. (OK, your eyes *are* far enough apart to sort of see in 3D, so perhaps I should call distance perception another half a dimension).
Also, what do you generally use layered 2D GUIs for? Apart from the obvious (being able to display graphics easily), one of the main advantages of, say, Windows over DOS or [some Unixish OS]+X11 over [same Unixish OS]+console is that you can *visually* leave things in the background. It's a nice intuitive metaphor.
(In the case of Windows, it's a larger advantage for Win95 or later, which can actually cope with *running* your multiple tasks if it feels like it:-)
OK, so DOS had background printing, Unix shells let you do "make mybigproject &" to run a background job, and some Unixish OSs (I'm sure Linux isn't the only one) have things like Linux's virtual terminals, but there's a certain usability advantage to "physically" leaving (say) your e-mail client in the background while you start up your browser/word processor/text editor/shell/whatever to retrieve something you want to paste into your e-mail, and being able to see bits of it "in the background" partly hidden by the new window.
Indeed, I know at least one Linux user whose only use for X is to run several terminal emulators at a time and have a screen size not limited by the usual 80x25. (Or so he claims... I know it's the games really:-)
"It is entirely possible to have this part of the code isolated from the rest of the code, and for it to be completely platform independant."
This applies nicely to other stuff too.
Have you seen the Unreal engine, responsible for Unreal, UT, Rune, Deus Ex and others? Video, audio, input, physics, etc. are implemented in C++ for speed. The game code ("when the player touches a gun lying on the ground, add it to their inventory" and so on) is written in UnrealScript, a compiled-to-bytecode language vaguely similar to Java. In the case of UT, you'd probably be surprised how much is done in Unrealscript (you could quite conceivably make a whole new game without changing the C++ bits, although you'd be stuck with a slightly older graphics engine that way).
I believe Quake 3 uses a similar system (mostly so that auto-downloaded mods can't carry viruses because they run in a Java-applet-like "sandbox"). This is why the UT and Quake 3 Linux ports consist of a smallish set of replacement binaries (the UT one is around the same size as the latest Windows UT update patch), and require a Windows CD to install from.
Re:What should we do.
on
Globalization
·
· Score: 2, Interesting
"Currently our country and way of life cannot continue if we were to be cut off from that oil. We are currently working to eliminate our demendency on it, but untill that happens, if we want to keep our way of life, we have to maintain a presence in the Middle East. It cant simply be argued out by philosophies, it simply is a fact that we need that oil."
Americans and oil... Someone posted elsewhere on this thread about SUVs and Starbucks and MacDonalds, and one reply said "yeah, SUVs haven't taken off in Europe, but that's because gasoline's expensive there".
You ever wonder why our fuel's expensive, when we're so much closer to the main source? Possibly deliberate taxation policies, to make the alternatives comparatively cheap and encourage research into them? European governments tax oil for a reason. It's not going to last forever, you know. (Estimates of the number of years' worth we have (at current usage) vary, but rarely have 3 digits in them; and by "we" here I don't mean Europeans, I mean the world.)
Observe huge strikes and blockades of refineries by UK truck drivers last summer, in protest at fuel tax rises. These basically stopped the UK for several days, but had precisely no effect on tax levels. If the government here just wanted the money, they could have dropped fuel taxes a bit and taxed something less conspicuous (or lots of less conspicuous things) instead; but they didn't. Does it sound like they want to hold on to that particular tax, for reasons other than just getting the money?
Yes, cars are part of The American Way Of Life. Yes, in a country that big, I suppose they have to be. But that's no reason to be excessive about them... it is possible to live in a fairly American-ish way while not using as much oil (see: UK, France, Germany, I can't be bothered to list the rest of western Europe but you probably get the idea).
<p>Use of <p> as a glorified line break is deprecated. It's a non-empty tag. It surrounds a paragraph, like this one (since I'm posting in HTML anyway, I've faked an extra p tag to illustrate it). I suppose use of <p> as anything except a paragraph is also deprecated.</p>
Actually, it's more important than <div> - a div tag has no particular significance (it's just a box with linebreaks for CSS and scripting to refer to), whereas a p tag definitely represents a paragraph (complete with conventional formatting like blank lines, which you can change to indents or something with CSS if you so wish). Remember, if you want unreadability, write continuous text; if you want legible writing, paragraph it (or that's what they told me at school anyway:-)
Indeed, the first tags Dave Raggett's HTML tutorial (hosted by the W3C) describes are title, h1 to h6, and p.
There's an easy way to do this, thanks to a Netscape 4 bug. Never use to load your stylesheet; use @import(foo.css); instead (both are fully standards compliant, and both use external stylesheets, which are A Good Thing). Netscape 4 never got round to implementing this, so NS4 users will see your site in not-so-glorious black-on-grey. But it'll work, which is a distinct improvement. You can even in the common bits plus Netscape kludges, and use for the IE/Opera/Mozilla/NS6/other-recent-browsers alterations.
Standards-compliant HTML which works in all browsers is nice, but contradictory. At the moment the best compromise I can find is:
use a Netscape 4 bug to break my Cascading Style Sheets in NS 3 and 4, because when I didn't, I had overlapping images, illegible text and all sorts of nastiness (the old Netscape rendering engine got confused easily it appears)
horizontal rules (<hr/>) hidden using CSS, so CSS browsers will display borders+colours between areas, and non-CSS browsers (Lynx/Netscape 4/etc) will display a horizontal rule instead
writing XHTML and CSS using the subset supported by recent versions of the Big Two (i.e. the stuff a standards-compliant browser should cope with, minus IE/NS/Mozilla bugs)
avoiding making risky features critical: I don't use Java at the moment, and if I did I definitely wouldn't make a navbar or something similarly important with it. Similarly, I use Javascript for odd bits of automatic redirection, but only as a fallback from meta tags (which most browsers respect anyway), and there's a normal link as a fallback from the Javascript (so if you have a broken *and* non-JS browser, it just takes slightly longer to redirect).
Detecting browsers is often misused, but with older Javascript implementations the only way is sometimes to use a browser sniffer. If only there was a standard function like browser.does("DOM_2") or something so you could switch by features rather than browser... this also has the advantage that you won't do odd things to a browser which none of your detection code picks up (e.g. some new obscure browser which reported its own user agent string but used IE-compatible Javascript).
Still, pretty mouseovers are hardly critical if you give the Netscape users some almost-as-easy way to get at the menus. OTOH, I'm always really annoyed when sites have Flash or Java navbars, are inaccessible without the appropriate plugin, and give you a smug message about "get a real browser" as the alt text... especially when my Java plugin (Mozilla+Blackdown Java) runs modern <object> applets happily and ignores their backwards(-compatible), deprecated <applet> ones...
It occurs to me that a real terrorist would be using elaborately hidden, near-undetectable codeword systems about now. Counterstrike players, on the other hand, will cheerfully keep talking about terrorists with AK-47s planting bombs, taking hostages and assassinating the President... I wonder how the Carnivore operators cope with that one?
OK, fine, try GnuPG then. It's an open source implementation of the OpenPGP standard, and doesn't have US export restrictions (because it's German, and importing foreign encryption munitions _into_ the US is fine). It and recent PGP versions should be fully compatible (by default, it doesn't quite implement the OpenPGP standard, for compatibility with older PGP versions, but you can set it to pedantic standards-compliance mode if you want a fully correct implementation).
Re:Could someone smart explain this quote to me
on
Microsoft's Future
·
· Score: 2, Informative
AFAIK, it's sort of vaguely possible to run a Linux box (probably other OSs like BSD too) as a very thin client. You put a minimal OS (say, the Linux kernel, DHCP or BootP, and NFS utils) on a ROM, boot from it, and network-mount a NFS drive as the root partition. Upgrading and network troubleshooting become impossible though, and you need LAN-like connectivity to the NFS server.
Having said that, the general-use networked computers at my college (Macs and Win2K PCs) have a full OS and basically nothing else (they use a Netware server for apps). I don't know about the Macs (there are only a couple and I haven't used them) but the PCs take longer than they should to log in and ages to get enough network connectivity to run apps (and because Windows likes running services on login rather than on boot, this happens once per user...) Once they're running and have refreshed their list of what software they can get at, they're reasonably fast.
Personally, I much prefer installing software and knowing I have a working copy of whatever app on my hard disk...
Oops, no linebreaks. Anyone who wants to actually read my message, try this one:-)
At least one virus (I forget which one) relies on the fact that Outlook (or possibly OExpress) auto-plays attached WAV files. It's a Win32 binary with a slightly obscure but executable-ish name (.pif or something) and a MIME type of audio/wav.
The infection goes something like:
Outlook: Hmm, some audio in a format I know about. I'll play it.
Outlook: Hey, you, do something with this. *passes file to Windows*
Windows shell: Hmm, a DOS Program Information File. I'm meant to run those, I think. Hey, you, run this. *passes file to some other bit of Windows*
Some other bit of Windows: Now how do I execute this? Hmm... first two bytes say MZ... it contains fail-if-run-in-DOS backwards-compatibility cruft... so it's a native Win32 executable. *runs virus or trojan*
Two big mistakes here. Autoplaying the WAV in the first place must have seemed like a good idea at the time, but I know it'd annoy me having an arbitrary WAV play when I looked at my mail.
Then, OE doesn't actually tell Windows to *play* the WAV, just to do something with it - and all three of the conflicting ways to ID it (MIME, extension, magic numbers) cause the worst possible behaviour.
It's easy to blame m$, because they make the whole package. You never hear anyone saying Linux has bugs/exploits, because ppl will say, no, no it's not linux, that's Apache's fault.
Yes, and? The fact that MS software is so "integrated" is where a lot of its holes seem to come from. The viruses which auto-forward to all your friends rely on this chain of integration:
- Outlook Express renders HTML e-mail
- it does so using Internet Explorer (well, the MSHTML engine, which IE and Active Desktop share with it)
- client-side Web scripting (JScript and VBScript) is enabled for e-mail by default (at least in IE+OE 5.5; IE6 might change this, but I've been using Mozilla recently)
- the same scripting languages are recycled for system scripting with Windows Scripting Host; if there's a bug in the JScript or VBScript sandbox, it can be exploited
I don't know of anyone who actually *uses* WSH, but it's there anyway...
If you want to see if it [the patch] is installed, check the version numbers of the components affected.
OK, fine. Which cryptic 8.3-named DLL was the one with the exploit again?
Microsoft do not release source code, and thus you cannot patch their systems.
Yep... funny how BSD and Linux users tend to look down on and/or pity MS ones, isn't it?
How much easier could clicking "Windows Update" be, for God's sake? No messing around with RPMs and tars/tgz, dodgy makefiles, incompatible libs etc.
OK, you have a point there, unless of course your favourite distro runs on stable if rather out-of-date libraries, and has security fixes from newer libs back-ported to these ones::cough Debian stable cough:: (although I must admit, I use Debian unstable so I actually get new features too)
But the point is to not to make so easy for 12 year old muppets to get their hands on it.
Unless you're volunteering to police warez and crack sites, I think it's important that the distribution system for patches and advisories is somewhere near as fast as that for cracks and malicious exploits. We can't slow one down, so it's easier to speed the other up.
Like every other software company in the world -- this is old news.
Yes. Buffer overflows are old news too, but that doesn't mean they're somehow any better.
The other issue that relates to this one is secure as possible by default. This principle applies to all Internet usage of computers.
This is as ignorant broad sweeping generalisation. It barely needs replying too, but I'm sick of reading this sh*t.
Hopefully MS will get sick of it sometime, and do something...
a) Office Macros.
Yes, they are a problem. They make life easy for you, but of course if you've spent your life writing Perl scripts in VI, you're never going to understand it. There is a problem inherent in the macro system, but it is more complicated than just disabling a few features.
Perhaps just not installing macros by default would help. If you (or for people in an office, your sysadmin/database guru/etc) don't know you need macros, you probably don't.
Or (too late for Microsoft for compatibility reasons, but a newer office suite could do this) the macros could be in external files, so the Word.doc or whatever only contained a hook requesting that a particular macro be run. You or your sysadmin could specify particular macro libraries that were allowed (so someone using a macro their employer's IT people set up could access a shared macro library from a secure or indeed read-only network drive).
This works better on OSs/filesystems with access control (Unixes, Netware, maybe NTFS?) where the macro library location could be only writable by your friendly local sysadmin.
(much like the idea that on Unix systems, running stuff from/usr/bin is safe because only root can write there, but the current directory isn't in the default path because you might be in/tmp which is world-writable)
Yes, well spotted! M$ software allows you to send attachments in email, isn't that innovation at it's best. Oops, so does every other email program pretty much on any platform. What's that? You can save the attachments and run them? My God! What's your point? I can send you a Tcl script or an ELF binary via email, but will _you_ save it and run it without checking? Where is the real problem here?
Yes, I'd check it before I ran it, if I ran it at all.
This is why I object if (when?) my mail client runs it for me.
At least one virus (I forget which one) relies on the fact that Outlook (or possibly OExpress) auto-plays attached WAV files. It's a Win32 binary with a slightly obscure but executable-ish name (.pif or something) and a MIME type of audio/wav.
The infection goes something like:
Outlook: Hmm, some audio in a format I know about. I'll play it.
Outlook: Hey, you, do something with this. *passes file to Windows*
Windows shell: Hmm, a DOS Program Information File. I'm meant to run those, I think. Hey, you, run this. *passes file to some other bit of Windows*
Some other bit of Windows: Now how do I execute this? Hmm... first two bytes say MZ... it contains fail-if-run-in-DOS backwards-compatibility cruft... so it's a native Win32 executable. *runs virus or trojan*
Two big mistakes here. Autoplaying the WAV in the first place must have seemed like a good idea at the time, but I know it'd annoy me having an arbitrary WAV play when I looked at my mail.
Then, OE doesn't actually tell Windows to *play* the WAV, just to do something with it - and all three of the conflicting ways to ID it (MIME, extension, magic numbers) cause the worst possible behaviour.
It's easy to blame m$, because they make the whole package. You never hear anyone saying Linux has bugs/exploits, because ppl will say, no, no it's not linux, that's Apache's fault.
Yes, and? The fact that MS software is so "integrated" is where a lot of its holes seem to come from. The viruses which auto-forward to all your friends rely on this chain of integration:
- Outlook Express renders HTML e-mail
- it does so using Internet Explorer (well, the MSHTML engine, which IE and Active Desktop share with it)
- client-side Web scripting (JScript and VBScript) is enabled for e-mail by default (at least in IE+OE 5.5; IE6 might change this, but I've been using Mozilla recently)
- the same scripting languages are recycled for system scripting with Windows Scripting Host; if there's a bug in the JScript or VBScript sandbox, it can be exploited
I don't know of anyone who actually *uses* WSH, but it's there anyway...
If you want to see if it [the patch] is installed, check the version numbers of the components affected.
OK, fine. Which cryptic 8.3-named DLL was the one with the exploit again?
Microsoft do not release source code, and thus you cannot patch their systems.
Yep... funny how BSD and Linux users tend to look down on and/or pity MS ones, isn't it?
How much easier could clicking "Windows Update" be, for God's sake? No messing around with RPMs and tars/tgz, dodgy makefiles, incompatible libs etc.
OK, you have a point there, unless of course your favourite distro runs on stable if rather out-of-date libraries, and has security fixes from newer libs back-ported to these ones::cough Debian stable cough:: (although I must admit, I use Debian unstable so I actually get new features too)
You also have a point about default installs on Linux running just as many servers as Win2k, although some distributions are better than others (Debian only installs a mail transport as standard, I think, and having a mail transport *is* pretty important on Unix).
But the point is to not to make so easy for 12 year old muppets to get their hands on it.
Unless you're volunteering to police warez and crack sites, I think it's important that the distribution system for patches and advisories is somewhere near as fast as that for cracks and malicious exploits. We can't slow one down, so it's easier to speed the other up.
Like every other software company in the world -- this is old news.
Yes. Buffer overflows are old news too, but that doesn't mean they're somehow any better.
The other issue that relates to this one is secure as possible by default. This principle applies to all Internet usage of computers.a) Office Macros.
Yes, they are a problem. They make life easy for you, but of course if you've spent your life writing Perl scripts in VI, you're never going to understand it. There is a problem inherent in the macro system, but it is more complicated than just disabling a few features.
Perhaps just not installing macros by default would help. If you (or for people in an office, your sysadmin/database guru/etc) don't know you need macros, you probably don't.
Or (too late for Microsoft for compatibility reasons, but a newer office suite could do this) the macros could be in external files, so the Word.doc or whatever only contained a hook requesting that a particular macro be run. You or your sysadmin could specify particular macro libraries that were allowed (so someone using a macro their employer's IT people set up could access a shared macro library from a secure or indeed read-only network drive).
This works better on OSs/filesystems with access control (Unixes, Netware, maybe NTFS?) where the macro library location could be only writable by your friendly local sysadmin.
(much like the idea that on Unix systems, running stuff from/usr/bin is safe because only root can write there, but the current directory isn't in the default path because you might be in/tmp which is world-writable)
Yes, well spotted! M$ software allows you to send attachments in email, isn't that innovation at it's best. Oops, so does every other email program pretty much on any platform. What's that? You can save the attachments and run them? My God! What's your point? I can send you a Tcl script or an ELF binary via email, but will _you_ save it and run it without checking? Where is the real problem here?
Yes, I'd check it before I ran it, if I ran it at all.
This is why I object if (when?) my mail client runs it for me.
Slashdot Mirror
Use Mozilla 0.95 and you will see the wonders of the <link> tag ;-)
Basically, they're a way for a web page author to specify related pages in a browser-independent, design-independent, extensible way, outside the main HTML of a page - think of them as "quick links" whose targets are defined by the page you're on. A long multi-page document might define Next, Previous and Contents to go to the obvious places, for instance. A website with content from many authors might define the Authors link so it goes to a list of this document's authors. A site with a specific copyright policy might link to it with the Copyright link. All of these are independent of the actual text in the HTML (they go in the <head> section) so if your browser doesn't support them, or you configure it not to, you'll never see them.
The W3C defined the meanings of quite a few links, and the Mozilla developers have added a couple more which they felt should be there for symmetry (W3C defined First, but not Last; Mozilla looks for Last too, for symmetry, and the Mozilla team have given the W3C a very short list of extras like Last which they think should go in the next HTML spec). You can use anything you like, though (Mozilla implements this by putting any unknown ones in a submenu).
Mozilla shows the <link>s as an extra toolbar, but there are other ways you could display them.
The defined ones are things like Previous, Next, First, Up, Top, Help, Authors, Search and Copyright - the sort of things many web pages and documents want. (At the moment Slashdot uses Top and Search).
Mozilla *is* made by Netscape. Yes, it's open-source, but most of the major contributors are Netscape employees who're paid to work on it. They then do an occasional code freeze, fix the most obvious bugs in the frozen version, add horrible branding, and call it Netscape 6.
The Gecko engine (Mozilla's renderer) has the advantage that, unlike NS4, it makes an effort to render non-legacy HTML correctly. Ever tried persuading Netscape 4 to work with perfectly correct Cascading Stylesheets? (Yes, I even tried running the W3C validator on them. They *were* valid.) It supports just enough CSS to try to parse the stylesheet, but not enough to get it right (overlapping images and text were a common problem for me). At the moment my website uses a loading method which *should* be supported, and is supported by everything else which uses CSS (IE, Mozilla/NS6, Opera, ...), specifically to trick NS4 into rendering the no-CSS simple-but-legible version instead of its broken half-CSS.
And that's quite impressive considering that
Having access to all the capabilities of your 2D monitor is a good thing too. Since your monitor displays in 2D and you basically see in 2D (assume your eyes are close together :-) this seems like an optimal number of dimensions to be using. "3D" games and OSs are limited to rendering 3D objects onto a 2D screen, but even if you had some sort of holodeck or something, where all 3 dimensions are rendered, you'd only see 2 at a time anyway. (OK, your eyes *are* far enough apart to sort of see in 3D, so perhaps I should call distance perception another half a dimension).
:-)
:-)
Also, what do you generally use layered 2D GUIs for? Apart from the obvious (being able to display graphics easily), one of the main advantages of, say, Windows over DOS or [some Unixish OS]+X11 over [same Unixish OS]+console is that you can *visually* leave things in the background. It's a nice intuitive metaphor.
(In the case of Windows, it's a larger advantage for Win95 or later, which can actually cope with *running* your multiple tasks if it feels like it
OK, so DOS had background printing, Unix shells let you do "make mybigproject &" to run a background job, and some Unixish OSs (I'm sure Linux isn't the only one) have things like Linux's virtual terminals, but there's a certain usability advantage to "physically" leaving (say) your e-mail client in the background while you start up your browser/word processor/text editor/shell/whatever to retrieve something you want to paste into your e-mail, and being able to see bits of it "in the background" partly hidden by the new window.
Indeed, I know at least one Linux user whose only use for X is to run several terminal emulators at a time and have a screen size not limited by the usual 80x25. (Or so he claims... I know it's the games really
Why stop at netcode?
"It is entirely possible to have this part of the code isolated from the rest of the code, and for it to be completely platform independant."
This applies nicely to other stuff too.
Have you seen the Unreal engine, responsible for Unreal, UT, Rune, Deus Ex and others? Video, audio, input, physics, etc. are implemented in C++ for speed. The game code ("when the player touches a gun lying on the ground, add it to their inventory" and so on) is written in UnrealScript, a compiled-to-bytecode language vaguely similar to Java. In the case of UT, you'd probably be surprised how much is done in Unrealscript (you could quite conceivably make a whole new game without changing the C++ bits, although you'd be stuck with a slightly older graphics engine that way).
I believe Quake 3 uses a similar system (mostly so that auto-downloaded mods can't carry viruses because they run in a Java-applet-like "sandbox"). This is why the UT and Quake 3 Linux ports consist of a smallish set of replacement binaries (the UT one is around the same size as the latest Windows UT update patch), and require a Windows CD to install from.
Americans and oil... Someone posted elsewhere on this thread about SUVs and Starbucks and MacDonalds, and one reply said "yeah, SUVs haven't taken off in Europe, but that's because gasoline's expensive there".
You ever wonder why our fuel's expensive, when we're so much closer to the main source? Possibly deliberate taxation policies, to make the alternatives comparatively cheap and encourage research into them? European governments tax oil for a reason. It's not going to last forever, you know. (Estimates of the number of years' worth we have (at current usage) vary, but rarely have 3 digits in them; and by "we" here I don't mean Europeans, I mean the world.)
Observe huge strikes and blockades of refineries by UK truck drivers last summer, in protest at fuel tax rises. These basically stopped the UK for several days, but had precisely no effect on tax levels. If the government here just wanted the money, they could have dropped fuel taxes a bit and taxed something less conspicuous (or lots of less conspicuous things) instead; but they didn't. Does it sound like they want to hold on to that particular tax, for reasons other than just getting the money?
Yes, cars are part of The American Way Of Life. Yes, in a country that big, I suppose they have to be. But that's no reason to be excessive about them... it is possible to live in a fairly American-ish way while not using as much oil (see: UK, France, Germany, I can't be bothered to list the rest of western Europe but you probably get the idea).
Since when was <p> deprecated? No sign of it here... XHTML v1.1 tags list
<p>Use of <p> as a glorified line break is deprecated. It's a non-empty tag. It surrounds a paragraph, like this one (since I'm posting in HTML anyway, I've faked an extra p tag to illustrate it). I suppose use of <p> as anything except a paragraph is also deprecated.</p>
Actually, it's more important than <div> - a div tag has no particular significance (it's just a box with linebreaks for CSS and scripting to refer to), whereas a p tag definitely represents a paragraph (complete with conventional formatting like blank lines, which you can change to indents or something with CSS if you so wish). Remember, if you want unreadability, write continuous text; if you want legible writing, paragraph it (or that's what they told me at school anyway :-)
Indeed, the first tags Dave Raggett's HTML tutorial (hosted by the W3C) describes are title, h1 to h6, and p.
There's an easy way to do this, thanks to a Netscape 4 bug. Never use to load your stylesheet; use @import(foo.css); instead (both are fully standards compliant, and both use external stylesheets, which are A Good Thing). Netscape 4 never got round to implementing this, so NS4 users will see your site in not-so-glorious black-on-grey. But it'll work, which is a distinct improvement. You can even in the common bits plus Netscape kludges, and use for the IE/Opera/Mozilla/NS6/other-recent-browsers alterations.
Standards-compliant HTML which works in all browsers is nice, but contradictory. At the moment the best compromise I can find is:
Detecting browsers is often misused, but with older Javascript implementations the only way is sometimes to use a browser sniffer. If only there was a standard function like browser.does("DOM_2") or something so you could switch by features rather than browser... this also has the advantage that you won't do odd things to a browser which none of your detection code picks up (e.g. some new obscure browser which reported its own user agent string but used IE-compatible Javascript).
Still, pretty mouseovers are hardly critical if you give the Netscape users some almost-as-easy way to get at the menus. OTOH, I'm always really annoyed when sites have Flash or Java navbars, are inaccessible without the appropriate plugin, and give you a smug message about "get a real browser" as the alt text... especially when my Java plugin (Mozilla+Blackdown Java) runs modern <object> applets happily and ignores their backwards(-compatible), deprecated <applet> ones...
It occurs to me that a real terrorist would be using elaborately hidden, near-undetectable codeword systems about now. Counterstrike players, on the other hand, will cheerfully keep talking about terrorists with AK-47s planting bombs, taking hostages and assassinating the President... I wonder how the Carnivore operators cope with that one?
OK, fine, try GnuPG then. It's an open source implementation of the OpenPGP standard, and doesn't have US export restrictions (because it's German, and importing foreign encryption munitions _into_ the US is fine). It and recent PGP versions should be fully compatible (by default, it doesn't quite implement the OpenPGP standard, for compatibility with older PGP versions, but you can set it to pedantic standards-compliance mode if you want a fully correct implementation).
AFAIK, it's sort of vaguely possible to run a Linux box (probably other OSs like BSD too) as a very thin client. You put a minimal OS (say, the Linux kernel, DHCP or BootP, and NFS utils) on a ROM, boot from it, and network-mount a NFS drive as the root partition. Upgrading and network troubleshooting become impossible though, and you need LAN-like connectivity to the NFS server.
Having said that, the general-use networked computers at my college (Macs and Win2K PCs) have a full OS and basically nothing else (they use a Netware server for apps). I don't know about the Macs (there are only a couple and I haven't used them) but the PCs take longer than they should to log in and ages to get enough network connectivity to run apps (and because Windows likes running services on login rather than on boot, this happens once per user...) Once they're running and have refreshed their list of what software they can get at, they're reasonably fast.
Personally, I much prefer installing software and knowing I have a working copy of whatever app on my hard disk...
At least one virus (I forget which one) relies on the fact that Outlook (or possibly OExpress) auto-plays attached WAV files. It's a Win32 binary with a slightly obscure but executable-ish name (.pif or something) and a MIME type of audio/wav.
The infection goes something like:
Outlook: Hmm, some audio in a format I know about. I'll play it.
Outlook: Hey, you, do something with this. *passes file to Windows*
Windows shell: Hmm, a DOS Program Information File. I'm meant to run those, I think. Hey, you, run this. *passes file to some other bit of Windows*
Some other bit of Windows: Now how do I execute this? Hmm... first two bytes say MZ... it contains fail-if-run-in-DOS backwards-compatibility cruft... so it's a native Win32 executable. *runs virus or trojan*
Two big mistakes here. Autoplaying the WAV in the first place must have seemed like a good idea at the time, but I know it'd annoy me having an arbitrary WAV play when I looked at my mail.
Then, OE doesn't actually tell Windows to *play* the WAV, just to do something with it - and all three of the conflicting ways to ID it (MIME, extension, magic numbers) cause the worst possible behaviour.
It's easy to blame m$, because they make the whole package. You never hear anyone saying Linux has bugs/exploits, because ppl will say, no, no it's not linux, that's Apache's fault.
Yes, and? The fact that MS software is so "integrated" is where a lot of its holes seem to come from. The viruses which auto-forward to all your friends rely on this chain of integration:
- Outlook Express renders HTML e-mail
- it does so using Internet Explorer (well, the MSHTML engine, which IE and Active Desktop share with it)
- client-side Web scripting (JScript and VBScript) is enabled for e-mail by default (at least in IE+OE 5.5; IE6 might change this, but I've been using Mozilla recently)
- the same scripting languages are recycled for system scripting with Windows Scripting Host; if there's a bug in the JScript or VBScript sandbox, it can be exploited
I don't know of anyone who actually *uses* WSH, but it's there anyway...
If you want to see if it [the patch] is installed, check the version numbers of the components affected.
OK, fine. Which cryptic 8.3-named DLL was the one with the exploit again?
Microsoft do not release source code, and thus you cannot patch their systems.
Yep... funny how BSD and Linux users tend to look down on and/or pity MS ones, isn't it?
How much easier could clicking "Windows Update" be, for God's sake? No messing around with RPMs and tars/tgz, dodgy makefiles, incompatible libs etc.
OK, you have a point there, unless of course your favourite distro runs on stable if rather out-of-date libraries, and has security fixes from newer libs back-ported to these ones ::cough Debian stable cough:: (although I must admit, I use Debian unstable so I actually get new features too)
But the point is to not to make so easy for 12 year old muppets to get their hands on it.
Unless you're volunteering to police warez and crack sites, I think it's important that the distribution system for patches and advisories is somewhere near as fast as that for cracks and malicious exploits. We can't slow one down, so it's easier to speed the other up.
Like every other software company in the world -- this is old news.
Yes. Buffer overflows are old news too, but that doesn't mean they're somehow any better.
The other issue that relates to this one is secure as possible by default. This principle applies to all Internet usage of computers.
This is as ignorant broad sweeping generalisation. It barely needs replying too, but I'm sick of reading this sh*t.
Hopefully MS will get sick of it sometime, and do something...
a) Office Macros.
Yes, they are a problem. They make life easy for you, but of course if you've spent your life writing Perl scripts in VI, you're never going to understand it. There is a problem inherent in the macro system, but it is more complicated than just disabling a few features.
Perhaps just not installing macros by default would help. If you (or for people in an office, your sysadmin/database guru/etc) don't know you need macros, you probably don't. Or (too late for Microsoft for compatibility reasons, but a newer office suite could do this) the macros could be in external files, so the Word .doc or whatever only contained a hook requesting that a particular macro be run. You or your sysadmin could specify particular macro libraries that were allowed (so someone using a macro their employer's IT people set up could access a shared macro library from a secure or indeed read-only network drive).
This works better on OSs/filesystems with access control (Unixes, Netware, maybe NTFS?) where the macro library location could be only writable by your friendly local sysadmin. (much like the idea that on Unix systems, running stuff from /usr/bin is safe because only root can write there, but the current directory isn't in the default path because you might be in /tmp which is world-writable)
Yes, well spotted! M$ software allows you to send attachments in email, isn't that innovation at it's best. Oops, so does every other email program pretty much on any platform. What's that? You can save the attachments and run them? My God! What's your point? I can send you a Tcl script or an ELF binary via email, but will _you_ save it and run it without checking? Where is the real problem here?
Yes, I'd check it before I ran it, if I ran it at all. This is why I object if (when?) my mail client runs it for me.
At least one virus (I forget which one) relies on the fact that Outlook (or possibly OExpress) auto-plays attached WAV files. It's a Win32 binary with a slightly obscure but executable-ish name (.pif or something) and a MIME type of audio/wav. The infection goes something like: Outlook: Hmm, some audio in a format I know about. I'll play it. Outlook: Hey, you, do something with this. *passes file to Windows* Windows shell: Hmm, a DOS Program Information File. I'm meant to run those, I think. Hey, you, run this. *passes file to some other bit of Windows* Some other bit of Windows: Now how do I execute this? Hmm... first two bytes say MZ... it contains fail-if-run-in-DOS backwards-compatibility cruft... so it's a native Win32 executable. *runs virus or trojan* Two big mistakes here. Autoplaying the WAV in the first place must have seemed like a good idea at the time, but I know it'd annoy me having an arbitrary WAV play when I looked at my mail. Then, OE doesn't actually tell Windows to *play* the WAV, just to do something with it - and all three of the conflicting ways to ID it (MIME, extension, magic numbers) cause the worst possible behaviour. It's easy to blame m$, because they make the whole package. You never hear anyone saying Linux has bugs/exploits, because ppl will say, no, no it's not linux, that's Apache's fault. Yes, and? The fact that MS software is so "integrated" is where a lot of its holes seem to come from. The viruses which auto-forward to all your friends rely on this chain of integration: - Outlook Express renders HTML e-mail - it does so using Internet Explorer (well, the MSHTML engine, which IE and Active Desktop share with it) - client-side Web scripting (JScript and VBScript) is enabled for e-mail by default (at least in IE+OE 5.5; IE6 might change this, but I've been using Mozilla recently) - the same scripting languages are recycled for system scripting with Windows Scripting Host; if there's a bug in the JScript or VBScript sandbox, it can be exploited I don't know of anyone who actually *uses* WSH, but it's there anyway... If you want to see if it [the patch] is installed, check the version numbers of the components affected. OK, fine. Which cryptic 8.3-named DLL was the one with the exploit again? Microsoft do not release source code, and thus you cannot patch their systems. Yep... funny how BSD and Linux users tend to look down on and/or pity MS ones, isn't it? How much easier could clicking "Windows Update" be, for God's sake? No messing around with RPMs and tars/tgz, dodgy makefiles, incompatible libs etc. OK, you have a point there, unless of course your favourite distro runs on stable if rather out-of-date libraries, and has security fixes from newer libs back-ported to these ones ::cough Debian stable cough:: (although I must admit, I use Debian unstable so I actually get new features too)
You also have a point about default installs on Linux running just as many servers as Win2k, although some distributions are better than others (Debian only installs a mail transport as standard, I think, and having a mail transport *is* pretty important on Unix).
But the point is to not to make so easy for 12 year old muppets to get their hands on it.
Unless you're volunteering to police warez and crack sites, I think it's important that the distribution system for patches and advisories is somewhere near as fast as that for cracks and malicious exploits. We can't slow one down, so it's easier to speed the other up.
Like every other software company in the world -- this is old news.
Yes. Buffer overflows are old news too, but that doesn't mean they're somehow any better.
The other issue that relates to this one is secure as possible by default. This principle applies to all Internet usage of computers.
a) Office Macros.
Yes, they are a problem. They make life easy for you, but of course if you've spent your life writing Perl scripts in VI, you're never going to understand it. There is a problem inherent in the macro system, but it is more complicated than just disabling a few features.
Perhaps just not installing macros by default would help. If you (or for people in an office, your sysadmin/database guru/etc) don't know you need macros, you probably don't.
Or (too late for Microsoft for compatibility reasons, but a newer office suite could do this) the macros could be in external files, so the Word .doc or whatever only contained a hook requesting that a particular macro be run. You or your sysadmin could specify particular macro libraries that were allowed (so someone using a macro their employer's IT people set up could access a shared macro library from a secure or indeed read-only network drive).
This works better on OSs/filesystems with access control (Unixes, Netware, maybe NTFS?) where the macro library location could be only writable by your friendly local sysadmin.
(much like the idea that on Unix systems, running stuff from /usr/bin is safe because only root can write there, but the current directory isn't in the default path because you might be in /tmp which is world-writable)
Yes, well spotted! M$ software allows you to send attachments in email, isn't that innovation at it's best. Oops, so does every other email program pretty much on any platform. What's that? You can save the attachments and run them? My God! What's your point? I can send you a Tcl script or an ELF binary via email, but will _you_ save it and run it without checking? Where is the real problem here?
Yes, I'd check it before I ran it, if I ran it at all.
This is why I object if (when?) my mail client runs it for me.