Nonsense. If you can write a buggy HTML document, you can also write a compliant one.
Sorry, but you overestimate the ability of much of the population. Many people building web pages do not fully understand what they are doing. The copy and paste other code, and when it looks right to them in Internet Explorer, they feel they are done.
Remember, in this case they wouldn't have been done.
They would have tried to look at their web page,
and gotten an error message instead.
They don't know their HTML code is buggy, and they wouldn't be able to fix it if they did. This type of person isn't stupid. They just do not have the interest or inclination for technology that you have. I'm sure they have other skills that would amaze you.
I know a few non-programmers, thank you very much.
Here we're talking about people writing HTML in a text editor
(authoring tools would have been compliant, or they would have been useless)
and the critical event is when they try to view the page.
How badly can it go wrong?
"there is no tag EMM (line 42)".
"you didn't end the UL list you started on line 188".
Stuff like that.
Stuff that doesn't guarantee the page renders the same everywhere,
but at least guarantees you can write a parser for it, without a lot of heuristics.
I agree -- halfway. Had early web browsers been strict about errors, we wouldn't have so much broken code out there, and cross-browser compatibility would be solely a matter of which features are supported -- not which set of error-correcting assumptions you expect.
Right. Well put.
On the other hand, the fact that those early versions of Mosaic, Netscape, IE, etc. would do something with broken code instead of refusing to display it meant that the barriers to entry were a lot lower. It vastly increased the pool of people who could create web pages, and the talent pool. Sure, some people have both artistic talent and programming ability, or have the resources to team up. But can you imagine a web built solely by programmers?
Nonsense.
If you can write a buggy HTML document, you can also write a compliant one.
You don't suddenly need a bloody programmer!
Especially not if the browsers themselves (or external validators) had given reasonably helpful
error messages, which they would have.
Apple manages to support 32-bit and 64-bit architectures for both PPC and Intel. Linux supports *tons* of different architectures. Why is it that it's a particular stumbling block for Microsoft and Microsoft developers?
I'm not a developer, so I'll admit that I'm not really that knowledgeable, but it seems to me that if it's too difficult for programmers to support different architectures [...]
I am, and it's not. Unless you move to really exotic architectures
with 16-bit chars or ints or something, or if your code sucks, or if
it's written in assembler.
The odd bug might turn up, but nothing out of the ordinary.
Moving between big- and little-endian would add a bit to the risk.
If you write in higher-level languages than C (like Perl or Python) chances something goes wrong are really slim.
Computer programs do not all have the same function.
Most computer programs have a common set of identical functionality. Some examples are manipulating windows (resizing, closing, etc), manipulating files (open, save, etc), manipulating text (copy, paste, etc), online help, changing settings.
Maybe most programs on your computer, but a tiny fraction on mine.
The grandparent was simply contrasting GUI type of program with a
non-interactive command line program, and suggesting that you cannot apply the
same style guidelines to both.
And there are other classes of user interfaces too:
Unix filters, shell-like programs,
full-screen terminal-based programs,
daemons...
Apple-like style guidelines are fine,
as long as they recognize that there are other user interface metaphors.
Simple, only the ODF document can be authoritative. Any derivative document can not be considered authoritative by default as it is not the Gov't spec'd format
.
Or, I could (if I worked for the Norwegian government) keep doing what I do:
write my documents with emacs, typeset them with troff, and generate PDF.
Word processors are evil, no matter what format they keep their files in.
I remember a friend that was configuring an Apache installation on a Sun and, once finished, decided to restart the process with a "killall httpd", like he would do on a Linux machine. The problem here is that the machine was also working as a gateway to the internet and Sun "killall" actually kills every single process, not the one named in the parameters. Five seconds and all the phones start ringing, with people asking what the heck was wrong with the internet.
It's worth noting that this his, or Gnu's fault.
The killall(1M) man page on Solaris 8 is dated September 1992...
pkill(1) is a better choice.
Also, it is an interesting thought when you ask yourself what "better linux" actually means. Will they offer things like iNotify and other kernel APIs or they meant the whole GNU/Linux stack?
A "better Linux" is one where I've recompiled the kernel without that iNotify crap.
I mean, just look at its name!
The major things i like about google's web based word app are:
1) it is someone else's responsibility to back it up, cluster it, load balance it, and improve it,
2) it is social, i can include other people in on my document edits easily,
3) i can effortlessly access it from anywhere, be it uni, work, home or a cafe.
Home based servers currently have none of the above
Mine has (2) and (3) and as for (1), clustering/load balancing is of course not needed.
I'd happily let some organization do my backups, if it could be trusted.
Hell, I'd replace my home server with a Unix shell account at some ISP,
if I felt I could trust one.
Also a good man page and a '--help' option for CLI utilities is always welcome. However a lot of people and 'new converts' to free operating systems tend to stick with the GUI for help, so HTML documentation that's easily accessible is a must.
Ridiculous. Man pages are the standard documentation for Unix programs.
If people refuse to read those (a matter of typing the word "man") it's their problem.
A Linux distribution which wants to be really user-friendly could easily include a web interface
which provides an index, searching, and PDF+HTML versions of all man pages on the system.
(Hmm... nice idea. Maybe I'll write one tonight.)
In fact it's usually buried somewhere in/usr/share or the like, and often programs don't tell you how to get at it easily.
/usr/share/doc/package is the standard place for non-manpage documentation
in most or all Linux distribution. How is that being "buried"? Point your browser to
file:///usr/share/doc/ and it's all there.
The you pretty much want to stay away for most Open Source projects. I have yet to meet an Open Source project lead (not just someone that commits to a project) that doesn't have an exaggerated sense of entitlement. This is why the documentation sucks in general. Notice I said most, and I haven't met. Yes there are some decent OSS projects that actually document their work, but these are few and far between.
Exactly which projects are you talking about?
Because I use exclusively open source programs at home, and the only ones with sucky documentation
that come to mind are the Linux kernel, udev, ntp, gnuplot, gtk and... no, those are the only ones.
Maybe it's those fancy Gnome programs that have sucky docs? I don't use those.
Speak for yourself. I'm sure most developers more than welcome someone to do the writing for them, myself included.
Speak for yourself. I prefer doing my own documentation,
because it helps me understand my features and my user interface.
Also, if I don't do it, the documentation will be badly written or incorrect,
and the users will come and bother me with silly questions and I will be unable
to tell them to RTFM.
I had hoped that after all these years, the % of females who use Linux would have improved. Granted, this is only SUSE, but 539 out of 27000 isn't very good odds.
But we could have one hell of a bukakke session!
Well maybe if people like you stopped making such gross remarks about women, more women would join the community.
Or at least women with no sense of humor.
The point of that joke was obviously directed at the male users, not women.
Otherwise, it wouldn't have been funny.
I have used the Linux commandline in numerous stages of my life (as also DOS and even VMS) and I wasn't impressed. Memorizing arcane commands to do simple things (vi as a text editor is an extreme example of its absurdity) is on par with memorizing Clebsch-Gordon coefficients:P.
You are wrong, or at least wired differently from me and other command-line people.
It's not about memorizing arcane commands.
It's about being able and willing to research the tools while using them.
"How can I use the find command to list all files larger than a gigabyte?
*browses the man page* Oh, that's how. *back to work*" If you still know how two weeks later; fine. If not, you simply read the man page again.
And seriously, how is a GUI better?
Take the MS Word preferences which I battled yesterday.
A tiny window filled with twelve tabbed screens which jump around at random,
each containing more than a dozen settings and frequently
sub-dialogues. And no useful reference documentation which explains what
these bloody settings actually do.
Above all, why it's become fashionable to run these tasks in your own personal RAM (*points to brain*) when the mindless computing machine in front of you can handle them quite easily is a mystery to me.
It's not fashion; many of us seriously believe the command-line way is superior for most tasks.
I truly cannot see how not doing that way somehow offloads work from your brain to the computer.
My experience is exactly the opposite --
pointless memorizing, futile searching and mindless repetive tasks is something I associate with
non-commandlines (i.e. using Windows and GUI applications).
Slightly off-topic, but I would not discount Clearcase on WAN. There are many reasons to hate Clearcase, but lack of distributed/wide area support is not one of them, thats actually one place I've seen it shine. Back in the day(about 10 years back) the company I worked for had part of the dev team in middle of nowhere China. The CC admin set up a satellite CC server in China and since the internet connection was unreliable (could not even reliably FTP a 10k file), he set up server-to-server sync via E-Mail. Warped enough but it worked like a charm, though it took a day or so, but the version control was being synced.
I am 95% sure that this setup means "branch A is mastered at site A, and branch B at site B".
Meaning people at site A would just see a read-only copy of branch B.
It's distributed alright, but with pretty severe limitations.
The XNA claim to be cross-platform is definitely a valid one, particularly when you consider that the X-Box 360 is a PowerPC architecture and Windows XP and Vista are primarily run on x86 chips.
Dude, code that compiles and runs for two processor architectures
isn't called "cross-platform".
It's called "not broken".
Assuming OS and APIs are identical,
you shouldn't have to praise that trait. You should take it for granted.
PATRIOT act has had a pretty damn large chilling effect. We haven't "lost" free speech in Europe either (I'm not including Russia in Europe, since even though half of it is technically within the geographical area of Europe, it is not a member of the European Union.)
Neither are Norway, Switzerland and several others.
The truth of the matter is, you can easily write a "Linux" application that runs on pretty much all major Linux distributions.
That is only true if you want to publish the source, and let the user do the compiling.
One cheap PC, N VMWare images each with one popular x86 distro installed.
There's your build environment for the majority of all Linux users.
Add a dualbooting Mac for the PPC users, and you cover even more.
However, even that solution makes it hard to reach out to the masses (if we can call Linux users masses). Many modern distro, when installed as a "Workstation", does not even install a compiler by default. People without a compiler have no use for sources.
What are you talking about?
All of them have a free compiler, a few seconds of installation away.
Installing it will surely be easier (and cheaper)
than installing your proprietary software.
And even then, in the presence of a compiler, I've seen my share of "./configure && make && make install" that failed.
How about a song for the thousands of victims tortured and killed under Castro's regime? You know, the people who weren't imprisioned for involvement in terrorism, but for such "crimes" as running an unauthorized library or demonstrating for democracy? Where are their songs?
I would caution you to take these reports with a grain of salt unless there is some other hard evidence to support them. The same kind of stuff was coming out of Eastern Europe in the 1980s and much of it turned out to be a fabrication. Cuban "commies" were always on the mild end of the spectrum, when compared to, say, China, whom apparently we are supposed to measure with a wholly different measure because they make golf-balls for Wal-Mart.
Comparisons are tricky, and I don't believe a person criticizing system A
always has to criticize systems B to Z at the same time to be believable.
That goes for both RMS and the poster two levels up.
Hey if you like 23234290234^345 sized megabyte applications where most of the program memory is used up by a bunch of redundant templates, then more power to yah (-:
Absurd.
Let's assume I use 5 kb of std::list<T> (and that's probably generous).
To use up a megabyte on that, my program would have to use lists of
200 different non-pointer types.
You should probably worry more about massive, recursive inlining.
The correct answer was that the authors of NT realized the ever-expanding and slow-to-process INI arrangement in earlier, simpler versions of Windows was doomed to failure.
s/realized/believed/, surely?
I mean, how can INI files be doomed when/etc is alive and well
after 35 years of growth?
And noone ever claimed that parsing/etc/fstab took too much time.
More ontopic,
my handling of new installations is based on precisely these text files.
I keep/etc and my ~ dotfiles in CVS (per host for/etc).
The only work needed (if the new machine runs the same software as the old one)
is adjusting for IP addresses, host names, accounts, hardware and other
such things that differ. That's tedious, but better than starting from
scratch.
And I install the software by diffing the 'dpkg -l' listings repeatedly.
And the reason why is because REXX is a scripting language, like Python or Perl. Bill Hawes did a great version of REXX for the Amiga. I scripted a lot of things in it!
Yeah, but unlike Perl and Python,
AREXX sucked, from a programming language point of view.
It worked as a scripting glue, but I wouldn't want to write a
substantial program in that language.
A C7 would likely be a much better choice for a webserver, you get SATA, and a much faster processor, which is much more suited to serving web traffic.
Since when do you need a fast processor to serve web pages
over a (most likely) fairly slow link?
And if you're hosting torrent files you will likely be having lots of disk access, making SATA a huge benefit.
Only if IDE disks cannot fill his internet connection.
I seriously doubt that is the case.
And how fast disks do you need to fill IDE, anyway?
Slashdot Mirror
Remember, in this case they wouldn't have been done. They would have tried to look at their web page, and gotten an error message instead.
I know a few non-programmers, thank you very much.
Here we're talking about people writing HTML in a text editor (authoring tools would have been compliant, or they would have been useless) and the critical event is when they try to view the page. How badly can it go wrong? "there is no tag EMM (line 42)". "you didn't end the UL list you started on line 188". Stuff like that. Stuff that doesn't guarantee the page renders the same everywhere, but at least guarantees you can write a parser for it, without a lot of heuristics.
Right. Well put.
Nonsense. If you can write a buggy HTML document, you can also write a compliant one. You don't suddenly need a bloody programmer! Especially not if the browsers themselves (or external validators) had given reasonably helpful error messages, which they would have.
I am, and it's not. Unless you move to really exotic architectures with 16-bit chars or ints or something, or if your code sucks, or if it's written in assembler. The odd bug might turn up, but nothing out of the ordinary. Moving between big- and little-endian would add a bit to the risk.
If you write in higher-level languages than C (like Perl or Python) chances something goes wrong are really slim.
Maybe most programs on your computer, but a tiny fraction on mine. The grandparent was simply contrasting GUI type of program with a non-interactive command line program, and suggesting that you cannot apply the same style guidelines to both.
And there are other classes of user interfaces too: Unix filters, shell-like programs, full-screen terminal-based programs, daemons ...
Apple-like style guidelines are fine, as long as they recognize that there are other user interface metaphors.
Or, I could (if I worked for the Norwegian government) keep doing what I do: write my documents with emacs, typeset them with troff, and generate PDF.
Word processors are evil, no matter what format they keep their files in.
I manage /etc on all my boxes with CVS, and I see no such problems.
The CVS used is various versions, plain and unpatched (except by Debian).
It's worth noting that this his, or Gnu's fault. The killall(1M) man page on Solaris 8 is dated September 1992 ...
pkill(1) is a better choice.
A "better Linux" is one where I've recompiled the kernel without that iNotify crap. I mean, just look at its name!
Mine has (2) and (3) and as for (1), clustering/load balancing is of course not needed. I'd happily let some organization do my backups, if it could be trusted. Hell, I'd replace my home server with a Unix shell account at some ISP, if I felt I could trust one.
A Linux distribution which wants to be really user-friendly could easily include a web interface which provides an index, searching, and PDF+HTML versions of all man pages on the system. (Hmm... nice idea. Maybe I'll write one tonight.)
Exactly which projects are you talking about? Because I use exclusively open source programs at home, and the only ones with sucky documentation that come to mind are the Linux kernel, udev, ntp, gnuplot, gtk and ... no, those are the only ones.
Maybe it's those fancy Gnome programs that have sucky docs? I don't use those.
Speak for yourself. I prefer doing my own documentation, because it helps me understand my features and my user interface. Also, if I don't do it, the documentation will be badly written or incorrect, and the users will come and bother me with silly questions and I will be unable to tell them to RTFM.
It should make you feel special.
Or better, you should try not to think too much of the relation between yourself and some piece of non-scientific, badly laid out statistics.
Or at least women with no sense of humor. The point of that joke was obviously directed at the male users, not women. Otherwise, it wouldn't have been funny.
You are wrong, or at least wired differently from me and other command-line people.
It's not about memorizing arcane commands. It's about being able and willing to research the tools while using them. "How can I use the find command to list all files larger than a gigabyte? *browses the man page* Oh, that's how. *back to work*" If you still know how two weeks later; fine. If not, you simply read the man page again.
And seriously, how is a GUI better? Take the MS Word preferences which I battled yesterday. A tiny window filled with twelve tabbed screens which jump around at random, each containing more than a dozen settings and frequently sub-dialogues. And no useful reference documentation which explains what these bloody settings actually do.
It's not fashion; many of us seriously believe the command-line way is superior for most tasks. I truly cannot see how not doing that way somehow offloads work from your brain to the computer. My experience is exactly the opposite -- pointless memorizing, futile searching and mindless repetive tasks is something I associate with non-commandlines (i.e. using Windows and GUI applications).
I am 95% sure that this setup means "branch A is mastered at site A, and branch B at site B". Meaning people at site A would just see a read-only copy of branch B.
It's distributed alright, but with pretty severe limitations.
Assuming OS and APIs are identical, you shouldn't have to praise that trait. You should take it for granted.
Comparisons are tricky, and I don't believe a person criticizing system A always has to criticize systems B to Z at the same time to be believable. That goes for both RMS and the poster two levels up.
s/realized/believed/, surely? I mean, how can INI files be doomed when /etc is alive and well
after 35 years of growth?
And noone ever claimed that parsing /etc/fstab took too much time.
More ontopic, my handling of new installations is based on precisely these text files. I keep /etc and my ~ dotfiles in CVS (per host for /etc).
The only work needed (if the new machine runs the same software as the old one)
is adjusting for IP addresses, host names, accounts, hardware and other
such things that differ. That's tedious, but better than starting from
scratch.
And I install the software by diffing the 'dpkg -l' listings repeatedly.
Yeah, but unlike Perl and Python, AREXX sucked, from a programming language point of view. It worked as a scripting glue, but I wouldn't want to write a substantial program in that language.
Only if IDE disks cannot fill his internet connection. I seriously doubt that is the case. And how fast disks do you need to fill IDE, anyway?