Yes - it's available under a semi-free licence that lets you distribute it alongside Linux, but it's still not free software. So Lesstif is not obsolete quite yet.
Huh? I thought Motif still was proprietary, even to this day. Or at least, it is proprietary software in the sense of not being free software. Or was there some big announcement I missed?
I think the penguin was adopted as a logo for Linux 2.0; it was probably drawn before then. Larry Ewing's page says it was based on 'discussions on the linux-kernel mailing list, and an initial suggestion by Alan Cox' but I don't know what this means.
According to O'Reilly's _Running Linux_, first edition, the storm petrel (a big white sea bird) was adopted as the mascot of the Linux project. That was back in the days of 1.0.x or 1.2.x - the penguin was a logo for Linux 2.0.
Typing in questions to other students might work in arts / essay subjects. But I don't see it working for maths courses - nobody can type the squiggly symbols, unless you are all lightning-fast TeX or MathML gurus, and even then stopping to type would probably be too much of a distraction from what the lecturer is saying. Anyway, the response you got back from other students would probably not help much to clarify things, since explaining mathematics takes time and is hard to do if you are only just learning it yourself.
Still, there could be a single red 'WTF?' button on the keyboard; when many people in the audience press it at once, you know you have some justification for interrupting the lecturer and asking him or her to explain.
Because there are far fewer top management than ordinary tech employees, cutting their salaries would have relatively little effect.
Even if someone at the top earns 100x as much as an ordinary employee, there are probably ten thousand ordinary employees for every top manager. So you'll make much bigger savings if you make cuts where most of the money is spent.
Plus, remember that the cost of employing someone isn't just their salary - in fact that can be rather a small part. If you move jobs overseas you also try to take advantage of cheaper land, lower taxes, fewer employment regulations and so on.
Yes, but it is possible that a defective reader will chew up the medium so you can't recover the data in any other reader (eg Iomega Zip 'click of death' a few years back). OK, this is unlikely to happen with optical devices.
Hard disks these days are usually quite reliable, and individual storage media can themselves fail too (eg a burned CD can deteriorate over time). We may reach a point where the reliability of a hard disk is just as good as that of a recordable CD or DVD. Of course, the hard disk is much more expensive (but it can be reused).
Yes - it looks like the majority of the 'spammers' tricks' listed are silly HTML tricks. From the messages I receive, a good rule of thumb is that HTML format implies spamminess. It might be different if you regularly have to communicate with Outhouse users.
HTML rendering was added to Pine only fairly recently. Given the quantity of HTML spam out there, it might have been a mistake.
Yes, I think Elvish was based on bits of various languages, but I don't think it counts as 'derived' from them in the sense of real people speaking one language and morphing it into another.
Not true that all Western languages are derivatives of Latin; only the 'romance' ones are (Portuguese, Spanish, French, Italian, Romanian, and many small languages / dialects like Occitan, Friulian or Corsican). English, Scots, German, Dutch, Flemish, Danish, Swedish and many others are Germanic languages and not derived directly from Latin, though they do share a common origin. Gaelic, Welsh, Breton and others are Celtic. (Copying words isn't enough to make a language a derivative of another - eg Japanese copies many words from English but is not a derivative of English.)
'derivatives of Latin and other languages' - well every language today spoken is the derivative of some other language, apart (arguably) from Elvish or Klingon etc.
The answer is simple... the anglophone world should refer to electronic mail as 'enamel' and then there will be a simple French translation. Knuth has already hinted at this.
If the Linux and Main article is accurate, Red Hat are experimenting with a big change to the classical model of producing distributions:
Currently, packages are "handed over" to Red Hat developers, who then tune them for inclusion in a particular version. Under the new system, developers will maintain control of the packages.
Until now there's always been a strong separation between developer and packager. Most distributions (particularly Debian) have thought of this as a Good Thing, though I don't remember the reasons right now.
I think Red Hat's move could work if the same strategy is shared by several distributions (and perhaps even by AIX or Solaris, if they adopt RPM) so that developers can maintain a non-distro-specific package. But many developers might not be happy about producing an RPM spec file just for Red Hat, or even just for Linux. Not everyone wants to pull in the same direction - the Apache developers try to make a web server, not to make a Linux web server or a part of GNU.
ImageMagick is great but I always feel that the same functionality must already be present in the GIMP, and it seems rather wasteful to have to learn two different tools to do the same job.
The GIMP is scriptable with Scheme or with Perl or other languages... perhaps all it needs is a good set of command-line interfaces as well?
Ah, this old chestnut. ISTR this comparison of formats was first mentioned on Slashdot a few years back.
I have to take issue with the 'usability by standard Linux tools' columns. RPM _is_ a standard Linux tool and it's easy to install it (or even just rpm2cpio) on systems that don't use it. Systems that don't use RPM would not be interested in RPM binary packages (maybe in source packages, but that's a consideration for only a few users). You might as well advocate making packages in.zip format because this is extractable on MS-DOS too; or storing all your images in xpm format because you can view it as a C header file in your text editor (urgh).
I think the earlier poster's proposed system would make life more usable for command-line junkies as well. If there were a file which defined the legal command-line parameters of a program, then shell tab completion would become a lot more useful (better even than the limited programmable completion that some shells currently have). For example you could type 'diff --supp' and hit tab to complete the long option to --suppress-common-lines. Similarly if an argument expects an integer or a filename, the shell could hint this to you as you type or when you press Tab.
We already have a formal description of the parameters a program expects - the string given to getopt() or Perl's Getopt::Long or any of a hundred other command-line-parsing libraries. Why not expose that knowledge in a known format to the outside world so that shells can use it to help the user?
You could even type-check your shell scripts to make sure each command is always invoked with legal arguments.
Re:Know why Linux will fail on the desktop?
on
Linux on the Desktop
·
· Score: 1
You can connect to MS SQL Server from Unix boxes, often using the Sybase client libraries. Of course I doubt that MS has made much of the useful admin functionality available over a remote connection.
Internet Explorer runs well under Wine, you could try the other three apps as well (it probably depends which version of VB).
In the worst case you could use VNC or rdesktop to view your Windows box in a window (heh) and avoid the need for a KVM switch.
Okay, but that's fourty-two zillion times better than dumping core seven minutes later for no apparent reason.
Yes, but in almost all C implementations dereferencing a null pointer will segfault the program there and then, letting you see the exact source line in the debugger. So apart from not having the line number printed as part of the error message, it is pretty much the same as Perl's behaviour.
The seven-minute-later-coredump thing happens when you start using pointers that are not null, but dodgy in some more subtle way, like pointing to freed space or off the end of an array.
Your computer is a "box"
It is no longer acceptable to refer to your computer as a machine, workstation, CPU, PC, server, etc. Your computer is a "box". And you must refer to your computer as a box at all times.
I propose a modification to this. When talking about gaming or about overclocking (and especially AMD systems), your computer is not a 'box' but a 'rig'. The correct phrase to express that your computer is fast is that it is a 'sweet rig'.
In Perl, the equivalent is undef, it stringifies to "" or numifies
to 0 regardless of platform, and _you can safely dereference it_.
Well firstly stringifying or numifying undef produces a warning in most circumstances - and the Perl developers themselves encourage you to turn on warnings (in fact it is considered a bug that -w is not mandatory). But more importantly, it's not true that undef can safely be dereferenced:
my $s;
print $$s;
gives Can't use an undefined value as a SCALAR reference.
What you showed in your code is an example of autovivification, where Perl creates data structures for you when values are set. It's the same as something like push @{$hash{hello}}, 55 where if the hash element was undef before, a new anonymous list will be created. But autovivification is for _setting_ values, there is no magic for ordinary dereferencing of undef, and that will crash your program just as dereferencing null will in C. (With a more helpful message, however.) FWIW, the code snippet you posted does not run because 'my $$x' is not legal.
I have been told that C++ also has references, but
for some reason people are still using pointers.
A lot of this is because they've picked up bad habits from older (or just plain bad) C++ textbooks. Modern C++ coding does not usually need pointers or explicit memory management that much, except for containers of pointers.
Slashdot Mirror
Yes - it's available under a semi-free licence that lets you distribute it alongside Linux, but it's still not free software. So Lesstif is not obsolete quite yet.
Huh? I thought Motif still was proprietary, even to this day. Or at least, it is proprietary software in the sense of not being free software. Or was there some big announcement I missed?
I think the penguin was adopted as a logo for Linux 2.0; it was probably drawn before then. Larry Ewing's page says it was based on 'discussions on the linux-kernel mailing list, and an initial suggestion by Alan Cox' but I don't know what this means.
According to O'Reilly's _Running Linux_, first edition, the storm petrel (a big white sea bird) was adopted as the mascot of the Linux project. That was back in the days of 1.0.x or 1.2.x - the penguin was a logo for Linux 2.0.
Typing in questions to other students might work in arts / essay subjects. But I don't see it working for maths courses - nobody can type the squiggly symbols, unless you are all lightning-fast TeX or MathML gurus, and even then stopping to type would probably be too much of a distraction from what the lecturer is saying. Anyway, the response you got back from other students would probably not help much to clarify things, since explaining mathematics takes time and is hard to do if you are only just learning it yourself.
Still, there could be a single red 'WTF?' button on the keyboard; when many people in the audience press it at once, you know you have some justification for interrupting the lecturer and asking him or her to explain.
Because there are far fewer top management than ordinary tech employees, cutting their salaries would have relatively little effect.
Even if someone at the top earns 100x as much as an ordinary employee, there are probably ten thousand ordinary employees for every top manager. So you'll make much bigger savings if you make cuts where most of the money is spent.
Plus, remember that the cost of employing someone isn't just their salary - in fact that can be rather a small part. If you move jobs overseas you also try to take advantage of cheaper land, lower taxes, fewer employment regulations and so on.
Yes, but it is possible that a defective reader will chew up the medium so you can't recover the data in any other reader (eg Iomega Zip 'click of death' a few years back). OK, this is unlikely to happen with optical devices.
Hard disks these days are usually quite reliable, and individual storage media can themselves fail too (eg a burned CD can deteriorate over time). We may reach a point where the reliability of a hard disk is just as good as that of a recordable CD or DVD. Of course, the hard disk is much more expensive (but it can be reused).
Yes - it looks like the majority of the 'spammers' tricks' listed are silly HTML tricks. From the messages I receive, a good rule of thumb is that HTML format implies spamminess. It might be different if you regularly have to communicate with Outhouse users.
HTML rendering was added to Pine only fairly recently. Given the quantity of HTML spam out there, it might have been a mistake.
But '_Who_ is Clippy?' is a much more interesting question.
Anyway, Klippy would presumably be the cease-n-desist-prone 'Assistant' in some future version of KDE...
(As others said, it's 'wer' not 'ver'. I think.)
Perhaps someone could clear this question up for me. Who would ever buy a motherboard branded 'Albatron'?
Yes, I think Elvish was based on bits of various languages, but I don't think it counts as 'derived' from them in the sense of real people speaking one language and morphing it into another.
Not true that all Western languages are derivatives of Latin; only the 'romance' ones are (Portuguese, Spanish, French, Italian, Romanian, and many small languages / dialects like Occitan, Friulian or Corsican). English, Scots, German, Dutch, Flemish, Danish, Swedish and many others are Germanic languages and not derived directly from Latin, though they do share a common origin. Gaelic, Welsh, Breton and others are Celtic. (Copying words isn't enough to make a language a derivative of another - eg Japanese copies many words from English but is not a derivative of English.)
'derivatives of Latin and other languages' - well every language today spoken is the derivative of some other language, apart (arguably) from Elvish or Klingon etc.
The answer is simple... the anglophone world should refer to electronic mail as 'enamel' and then there will be a simple French translation. Knuth has already hinted at this.
Probably the fastest XML parser possible is FleXML. You feed it the DTD for your format and it generates C code a la lex/yacc.
Until now there's always been a strong separation between developer and packager. Most distributions (particularly Debian) have thought of this as a Good Thing, though I don't remember the reasons right now.
I think Red Hat's move could work if the same strategy is shared by several distributions (and perhaps even by AIX or Solaris, if they adopt RPM) so that developers can maintain a non-distro-specific package. But many developers might not be happy about producing an RPM spec file just for Red Hat, or even just for Linux. Not everyone wants to pull in the same direction - the Apache developers try to make a web server, not to make a Linux web server or a part of GNU.
ImageMagick is great but I always feel that the same functionality must already be present in the GIMP, and it seems rather wasteful to have to learn two different tools to do the same job.
The GIMP is scriptable with Scheme or with Perl or other languages... perhaps all it needs is a good set of command-line interfaces as well?
News Story Template #7:
'RMS Sounded Like a Paranoid Wacko At The Time, But On This Particular Issue He Might Have Been Right All Along.'
So what are the units for measuring value for money in Internet connections?
Bits per second per (dollar per month)?
Bits per dollar?
Ah, this old chestnut. ISTR this comparison of formats was first mentioned on Slashdot a few years back.
.zip format because this is extractable on MS-DOS too; or storing all your images in xpm format because you can view it as a C header file in your text editor (urgh).
I have to take issue with the 'usability by standard Linux tools' columns. RPM _is_ a standard Linux tool and it's easy to install it (or even just rpm2cpio) on systems that don't use it. Systems that don't use RPM would not be interested in RPM binary packages (maybe in source packages, but that's a consideration for only a few users). You might as well advocate making packages in
I think the earlier poster's proposed system would make life more usable for command-line junkies as well. If there were a file which defined the legal command-line parameters of a program, then shell tab completion would become a lot more useful (better even than the limited programmable completion that some shells currently have). For example you could type 'diff --supp' and hit tab to complete the long option to --suppress-common-lines. Similarly if an argument expects an integer or a filename, the shell could hint this to you as you type or when you press Tab.
We already have a formal description of the parameters a program expects - the string given to getopt() or Perl's Getopt::Long or any of a hundred other command-line-parsing libraries. Why not expose that knowledge in a known format to the outside world so that shells can use it to help the user?
You could even type-check your shell scripts to make sure each command is always invoked with legal arguments.
You can connect to MS SQL Server from Unix boxes, often using the Sybase client libraries. Of course I doubt that MS has made much of the useful admin functionality available over a remote connection.
Internet Explorer runs well under Wine, you could try the other three apps as well (it probably depends which version of VB).
In the worst case you could use VNC or rdesktop to view your Windows box in a window (heh) and avoid the need for a KVM switch.
Yes, but in almost all C implementations dereferencing a null pointer will segfault the program there and then, letting you see the exact source line in the debugger. So apart from not having the line number printed as part of the error message, it is pretty much the same as Perl's behaviour.
The seven-minute-later-coredump thing happens when you start using pointers that are not null, but dodgy in some more subtle way, like pointing to freed space or off the end of an array.
They may not be boxes, but they are still boxen ;-).
I propose a modification to this. When talking about gaming or about overclocking (and especially AMD systems), your computer is not a 'box' but a 'rig'. The correct phrase to express that your computer is fast is that it is a 'sweet rig'.
Well firstly stringifying or numifying undef produces a warning in most circumstances - and the Perl developers themselves encourage you to turn on warnings (in fact it is considered a bug that -w is not mandatory). But more importantly, it's not true that undef can safely be dereferenced:
my $s;print $$s;
gives Can't use an undefined value as a SCALAR reference.
What you showed in your code is an example of autovivification, where Perl creates data structures for you when values are set. It's the same as something like push @{$hash{hello}}, 55 where if the hash element was undef before, a new anonymous list will be created. But autovivification is for _setting_ values, there is no magic for ordinary dereferencing of undef, and that will crash your program just as dereferencing null will in C. (With a more helpful message, however.) FWIW, the code snippet you posted does not run because 'my $$x' is not legal.
A lot of this is because they've picked up bad habits from older (or just plain bad) C++ textbooks. Modern C++ coding does not usually need pointers or explicit memory management that much, except for containers of pointers.