I remember the time when Cygnus couldn't be bothered with updating GCC for the Pentium instruction set. I remember their high handed disrespect, and I won't forget it.
They didn't have the resources to do that work unpaid -- and there is no reason why they should have done so.
If someone had paid them to do it, they would have done it. Nobody did.
Say that again? How is it that a *FREE* OS made by people that do not get paid for their services are able to enter the market and compete quite well? That's a high barrier?
The barrier is the cost of development of a new operating system. This requires such a large (manpower) investment that it has taken thousands of volunteers several years. To do this commercially would take many millions of dollars.
Question Regarding Upgrade
on
Red Hat 6.0
·
· Score: 1
I upgraded from 5.2 to 5.9 (this is the beta for 6.0). The beta version of inn and of tetex had problems which are now fixed. Other than that, the only other problem was that the upgrade installed Sendmail, replacing Postfix (which was not installed as an RPM).
Uninstalling sendmail and putting the/usr/local symlinks in fixed that, and now the system works fine.
My NFS mounts seem to have turned themselves read-only, but I haven't figured that one out, yet.
just when you thought everything coexisted happily
on
Red Hat 6.0
·
· Score: 1
Are we looking at a VHS/Beta fight with KDE and Gnome? How can we avoid this?
No, we're not looking at a fight here.
Red Hat 6.0 uses gdm at runlevel 5, not the normal xdm. This features a combo box which allows you to select a KDE or a GNOME login environment. Whichever you select, the menus for the others are also available. For example, the KDE menu tree lives in the "KDE Menus" option of the main menu on the GNOME panel.
The default theme of GNOME co-exists quote pleasingly with the way thet KDE looks, so you can use both sets of apps without things jarring.
Red Hat 6.0 blends KDE and GNOME together pretty well. These observations are, in fact, based on red Hat 5.9, which I am assuming wil be pretty similar.
It's important to remember that writing fewer lines of code is better than writing more, provided it gets the job done.
Fewer lines of code means fewer bugs, and usually makes the program easier to understand (since there is less code to read). There is a point where brevity turns into obfuscation, but that is usually on the micro-scale, and usually doesn't apply to whole programs.
Linux coders are biased against C++, that's why
on
Java for EGCS
·
· Score: 1
And those try{} catch{} blocks just feel way too much like some sort of basic. I want to program, not play a game of baseball.
You've completely missed the point of exceptions. In the real world, many bugs are in the end tracked down to poor checking of return values. For programs with significant amounts of external interaction, error-handling code can take up as much as 50 percent of the program.
Exceptions can provide a way to do this in a way that will ensure that all those errors are caught, and can be recovered from at the appropriate level. They're not always appropriate, but they can be extremely valuable.
C++, by contrast, feels like it was designed with OO theory in mind. It has all sorts of contructs that just don't feel right on a computer. Like the public/protected/private declarations. That just feels like something that should be in a classroom, not a real programming language
These are features that are essential for very large projects. They also turn out to be useful for small ones too, particularly if you propose to re-use your code. IMHO if you can't see the point of hiding the implementation of an object from its user while still exposing its interface, you haven't grasped one of the funamentals of object-oriented design.
blockquote Anyhow, I haven't seen any really good reasons for prefering one language over the other.
There aren't any. There is no single "better" language. It all depends on the application. For any given application, the "best" language mught be C++. It mught be C. It might be Perl, Awk, Yacc/Lex, Lisp, Python, or something else.
There's nothing that you can do in C++ that you can't do in C
Sure, and therte is nothing that you can do in Perl that you can't do in C, either. It's just more time-consuming to do it in C. The reverse can also be true, too.
This is too good to be true.
on
Java for EGCS
·
· Score: 1
I've been caught in the middle of trying to decide on a language to hitch my wagon to
You're asking the wrong question. The question you should be asking is "What language should I learn next?"
To be a great programmer you have to be able to pick the right language for the job. This means knowing C, Bourne Shell, Perl and Makefile, certainly. It probably also means knowing C++, Python, Lex, Yacc. Maybe SQL for certain kinds of applications. Awk, Scheme, Lisp for extra credit. You'll frequently end up using several of these in a single project. This is not an exhaustive list of useful languages. See Jon Bentley's books Programming Pearls and More Programming Pearls as well as Kernighan and Pike's The Practice of Programming for more discussion of these issues.
For example, the project I'm working on at work uses C, C++, SQL, and Bourne shell directly. Also Awk on the side.
Roadmap for Linux Gaming Support
on
Gaming on Linux
·
· Score: 1
I'd be quite happy to work on DDC for Linux [*], but I can't afford to lay out the $150 that VESA requires. The irony is that it's an open standard, (that is, anybody can get a copy).
[*] having blown up 2 monitors in the same month during 1995, I wish it had been done a long time ago:-)
One thing I've wanted to do but never got around to it is to sit in say a large IRC channel, like #linux, there's always 100+ in there. Then just sit back and see how many times someone tries to telnet/ftp/etc into your box.
I did that a while back. Opened 2 xterms, one running ircII, the other running tcpdump on the PPP interface. When I noticed a scan, I looked at the source, did/WHO, and asked the originator privately with a/MSG if they'd found anything interesting. Had some interesting conversations that way...
Dude, maybe 7% of the people in this freakin' country are as smart as the average person that reads (and understands)./
Many intelligent people don't understand./. They just don't grok computers, either because they have no exposure to the actual mechanisms (i.e. they don't know what's behind the "Start" menu) or because "Their brains are actually wired differently" (to quote ESR).
You write as if the goal of LSB is to create a uniform system, where no progress or differentiation can happen. This is not the case.
The principal benefit of LSB is that third party software vendors can just target "LSB 1.0" and hence support all distributions. This is a good idea, wouldn't you say?
In no way does this imply that any distribution needs to be hobbled by the LSB. I'm sure that if glibc 2.1 or 2.2 ends up as the library component of the LSB, and glibc 3 comes out, then distributions will move to it rapidly, while retaining support for LSB in exactly the way that a.out support is provided now.
If LSB also emerges as a useful development target for ISVs, then I assume that some distributions will provide GCC configurations that link against the "old" libraries as well as a GCC configuration which links against the latest stable glibc etc.
Binary RPMs contain the binaries (like tgz packages of binaries), plus information about what versions of which libraries and what other stuff is required (e.g. Perl,/bin/sh etc). When you install the RPM,/usr/bin/rpm checks you have all the prerequisites, and then installs the package. It updates its records to indicate what package these files belong to.
This means that to delete the stuff in the "cheops" package, you just rpm -e cheops. This is quote a bit easier than figuring out where alll the files got put in the first place. It also makes it harder to break your system by deleting something that another package relies on. However, this is Linux, so if you want to do that, you just use the --force option.
If you have an RPM of "foo" installed and want to upgrade it from a binary tgz file, just uninstall the old package (rpm -e foo) and unpack the tgz as usual. No problem.
I'm scared that when I get down to actually using RedHat, all the rc files and stuff is going to be a bunch of auto generated stuff I shouldn't touch
No, Red Hat keeps the rc scripts which start suff separate from the config scripts. Each rc script will read a config script and the start a daemon or whatever. This means that when an upgrade occurs, the rc script is upgraded, but your configuration information is not lost because it lives in a separate file.
All the normal Unix config files live in/etc, as usual./etc/hosts,/etc/resolv.conf and so on, just like on all other Unix systems. The config files that are specially for use by the/etc/rc.d startup scripts are all held in/etc/sysconfig.
All those various config files can be edited with Linuxconf, but you can still edit them by hand. You can change something with Linuxconf, and then tweak stuff by hand. Back to Linuxconf, and then back to vi if you feel like it. The two methods are completely compatible.
Personally, although I have used Red Hat for years now, I still edit the config files by hand, because that is what I am used to (I started with MCC Interim Linux after being an HPUX administrator for a bit). Red Hat is every bit as vi-configuration-friendly as Slackware and MCC, but the difference is that it also has optional configuration tools.
I guess I could live with a binary only distro
Eh? Red Hat is not a binary-only distro. It comes with the source for everything, the kernel, X, the/usr/bin/* stuff, the installation program, everything.
---snip--- The IPP Model document defines an IPP implementation with "privacy" as one that implements Secure Socket Layer Version 3 (SSL3). Note: SSL3 is not an IETF standards track specification. SSL3 meets the requirements for IPP security with regards to features such as mutual authentication and privacy (via encryption). The IPP Model document also outlines IPP-specific security considerations and should be the primary reference for security implications with regards to the IPP protocol itself.
The IPP Model document defines an IPP implementation with "authentication" as one that implements the standard way for transporting IPP messages within HTTP 1.1. These include the security considerations outlined in the HTTP 1.1 standard document [rfc2068] and Digest Access Authentication extension [rfc2069].
The current HTTP infrastructure supports HTTP over TCP port 80. IPP server implementations MUST offer IPP services using HTTP over the IANA assigned Well Known Port 631 (the IPP default port). IPP server implementations may support other ports, in addition to this port.
See further discussion of IPP security concepts in the model document [ipp-mod].
---snip---
If IPP is going to rely on SSL for security, that lets it in for all the difficulties of getting and using SSL that already exist.
Additionally, the whole specification looks pretty complex. Something of the second-system effect in there, I think. Expect to see IPP exploits on BugTraq.
I like the pure democracy idea of everyone being able to vote on articles.
The only danger is that of positive feedback. An opinion which is valuable (i.e. arguably true, insigntful, etc) isn't necessarily popular. It would be a bad thing if opinions which were not well received (i.e. Foobar has these flaws which need fixing) were moderated into invisibility just because everybody voted them down. For this reason, I'm quite happy with the ideas on moderation.
But then, I don't have the time to read all 200 comments on some of thre threads. I try to guess which ones are interesting by looking at the subjects, but you miss many cases where the reply is more interesting than the question, that way. Maybe I should experiment with my preference level.
"synchronous" metadata only protects the *metadata*, not the *file content data itself*.
So having mounts synchronous by default only ensures that the metadata is preserved correctly. This means that after an unexpected reboot, the data inside the files themselves may be junk, but at least it *looks* ok when you do an "ls -l". Is that so valuable?
If you want a filesystem that doesn't lose data, use a journaling filesystem. It's that simple.
The revolutions that the "digital age" is being compared to are revolutions in the availability of information and knowledge.
The inention of the printing press reduced the cost of book reproduction (while it would previously take a scribe several months to copy a book, it would take a printer slightly longer to print the first copy, but almost no time at all to print an extra hundred copies).
The Internet (rather than the digital computer) redices the cost of the distribution of information to a very low level. This does indeed have revolutionaty consequences.
Specifically, many organisations which exist to collect information and sell it for profit have already found themselves profoundly affected by the dawn of the worldwide network.
I wonder how different history would have been if copyright law had existed before the invention of the printing press.
Slashdot Mirror
If someone had paid them to do it, they would have done it. Nobody did.
Uninstalling sendmail and putting the /usr/local symlinks in fixed that, and now the system works fine.
My NFS mounts seem to have turned themselves read-only, but I haven't figured that one out, yet.
No, we're not looking at a fight here.
Red Hat 6.0 uses gdm at runlevel 5, not the normal xdm. This features a combo box which allows you to select a KDE or a GNOME login environment. Whichever you select, the menus for the others are also available. For example, the KDE menu tree lives in the "KDE Menus" option of the main menu on the GNOME panel.
The default theme of GNOME co-exists quote pleasingly with the way thet KDE looks, so you can use both sets of apps without things jarring.
Red Hat 6.0 blends KDE and GNOME together pretty well. These observations are, in fact, based on red Hat 5.9, which I am assuming wil be pretty similar.
If I were working for either VA or Red Hat, I'd find these comparisons really quite insulting.
Fewer lines of code means fewer bugs, and usually makes the program easier to understand (since there is less code to read). There is a point where brevity turns into obfuscation, but that is usually on the micro-scale, and usually doesn't apply to whole programs.
You've completely missed the point of exceptions. In the real world, many bugs are in the end tracked down to poor checking of return values. For programs with significant amounts of external interaction, error-handling code can take up as much as 50 percent of the program.
Exceptions can provide a way to do this in a way that will ensure that all those errors are caught, and can be recovered from at the appropriate level. They're not always appropriate, but they can be extremely valuable.
These are features that are essential for very large projects. They also turn out to be useful for small ones too, particularly if you propose to re-use your code. IMHO if you can't see the point of hiding the implementation of an object from its user while still exposing its interface, you haven't grasped one of the funamentals of object-oriented design.blockquote Anyhow, I haven't seen any really good reasons for prefering one language over the other.
There aren't any. There is no single "better" language. It all depends on the application. For any given application, the "best" language mught be C++. It mught be C. It might be Perl, Awk, Yacc/Lex, Lisp, Python, or something else.
Sure, and therte is nothing that you can do in Perl that you can't do in C, either. It's just more time-consuming to do it in C. The reverse can also be true, too.
You're asking the wrong question. The question you should be asking is "What language should I learn next?"
To be a great programmer you have to be able to pick the right language for the job. This means knowing C, Bourne Shell, Perl and Makefile, certainly. It probably also means knowing C++, Python, Lex, Yacc. Maybe SQL for certain kinds of applications. Awk, Scheme, Lisp for extra credit. You'll frequently end up using several of these in a single project. This is not an exhaustive list of useful languages. See Jon Bentley's books Programming Pearls and More Programming Pearls as well as Kernighan and Pike's The Practice of Programming for more discussion of these issues.
For example, the project I'm working on at work uses C, C++, SQL, and Bourne shell directly. Also Awk on the side.
I'd be quite happy to work on DDC for Linux [*], but I can't afford to lay out the $150 that VESA requires. The irony is that it's an open standard, (that is, anybody can get a copy).
:-)
[*] having blown up 2 monitors in the same month during 1995, I wish it had been done a long time ago
I did that a while back. Opened 2 xterms, one running ircII, the other running tcpdump on the PPP interface. When I noticed a scan, I looked at the source, did /WHO, and asked the originator privately with a /MSG if they'd found anything interesting. Had some interesting conversations that way...
But you have to include the amount of time it takes to get the data onto the tape and back off again.
Hell, I know English people with degrees in English Lit. who can't spell either.
The principal benefit of LSB is that third party software vendors can just target "LSB 1.0" and hence support all distributions. This is a good idea, wouldn't you say?
In no way does this imply that any distribution needs to be hobbled by the LSB. I'm sure that if glibc 2.1 or 2.2 ends up as the library component of the LSB, and glibc 3 comes out, then distributions will move to it rapidly, while retaining support for LSB in exactly the way that a.out support is provided now.If LSB also emerges as a useful development target for ISVs, then I assume that some distributions will provide GCC configurations that link against the "old" libraries as well as a GCC configuration which links against the latest stable glibc etc.
Binary RPMs contain the binaries (like tgz packages of binaries), plus information about what versions of which libraries and what other stuff is required (e.g. Perl, /bin/sh etc). When you install the RPM, /usr/bin/rpm checks you have all the prerequisites, and then installs the package. It updates its records to indicate what package these files belong to.
This means that to delete the stuff in the "cheops" package, you just rpm -e cheops. This is quote a bit easier than figuring out where alll the files got put in the first place. It also makes it harder to break your system by deleting something that another package relies on. However, this is Linux, so if you want to do that, you just use the --force option.
If you have an RPM of "foo" installed and want to upgrade it from a binary tgz file, just uninstall the old package (rpm -e foo) and unpack the tgz as usual. No problem.
No, Red Hat keeps the rc scripts which start suff separate from the config scripts. Each rc script will read a config script and the start a daemon or whatever. This means that when an upgrade occurs, the rc script is upgraded, but your configuration information is not lost because it lives in a separate file.
All the normal Unix config files live in /etc, as usual. /etc/hosts, /etc/resolv.conf and so on, just like on all other Unix systems. The config files that are specially for use by the /etc/rc.d startup scripts are all held in /etc/sysconfig.
All those various config files can be edited with Linuxconf, but you can still edit them by hand. You can change something with Linuxconf, and then tweak stuff by hand. Back to Linuxconf, and then back to vi if you feel like it. The two methods are completely compatible.
Personally, although I have used Red Hat for years now, I still edit the config files by hand, because that is what I am used to (I started with MCC Interim Linux after being an HPUX administrator for a bit). Red Hat is every bit as vi-configuration-friendly as Slackware and MCC, but the difference is that it also has optional configuration tools.
Eh? Red Hat is not a binary-only distro. It comes with the source for everything, the kernel, X, the /usr/bin/* stuff, the installation program, everything.
From draft-ietf-ipp-protocol-07.txt:-
---snip---
The IPP Model document defines an IPP implementation with "privacy" as
one that implements Secure Socket Layer Version 3 (SSL3). Note: SSL3
is not an IETF standards track specification. SSL3 meets the
requirements for IPP security with regards to features such as mutual
authentication and privacy (via encryption). The IPP Model document also
outlines IPP-specific security considerations and should be the primary
reference for security implications with regards to the IPP protocol
itself.
The IPP Model document defines an IPP implementation with
"authentication" as one that implements the standard way for
transporting IPP messages within HTTP 1.1. These include the security
considerations outlined in the HTTP 1.1 standard document [rfc2068] and
Digest Access Authentication extension [rfc2069].
The current HTTP infrastructure supports HTTP over TCP port 80. IPP
server implementations MUST offer IPP services using HTTP over the IANA
assigned Well Known Port 631 (the IPP default port). IPP server
implementations may support other ports, in addition to this port.
See further discussion of IPP security concepts in the model document
[ipp-mod].
---snip---
If IPP is going to rely on SSL for security, that lets it in for all the difficulties of getting and using SSL that already exist.
Additionally, the whole specification looks pretty complex. Something of the second-system effect in there, I think. Expect to see IPP exploits on BugTraq.
JetDirect cards already use TCP/IP. They look just like a normal BSD-style lpd print queue.
The only danger is that of positive feedback. An opinion which is valuable (i.e. arguably true, insigntful, etc) isn't necessarily popular. It would be a bad thing if opinions which were not well received (i.e. Foobar has these flaws which need fixing) were moderated into invisibility just because everybody voted them down. For this reason, I'm quite happy with the ideas on moderation.
But then, I don't have the time to read all 200 comments on some of thre threads. I try to guess which ones are interesting by looking at the subjects, but you miss many cases where the reply is more interesting than the question, that way. Maybe I should experiment with my preference level.
You're scared of "async"?
"synchronous" metadata only protects the *metadata*, not the *file content data itself*.
So having mounts synchronous by default only ensures that the metadata is preserved correctly. This means that after an unexpected reboot, the data inside the files themselves may be junk, but at least it *looks* ok when you do an "ls -l". Is that so valuable?
If you want a filesystem that doesn't lose data, use a journaling filesystem. It's that simple.
It's all about information, really.
The revolutions that the "digital age" is being compared to are revolutions in the availability of information and knowledge.
The inention of the printing press reduced the cost of book reproduction (while it would previously take a scribe several months to copy a book, it would take a printer slightly longer to print the first copy, but almost no time at all to print an extra hundred copies).
The Internet (rather than the digital computer) redices the cost of the distribution of information to a very low level. This does indeed have revolutionaty consequences.
Specifically, many organisations which exist to collect information and sell it for profit have already found themselves profoundly affected by the dawn of the worldwide network.
I wonder how different history would have been if copyright law had existed before the invention of the printing press.
No, they'll just think, "Cool! The web site is popular! We must have got it right!".
Bletch.