Re:How about a nice ROM Monitor instead?
on
Linux BIOS
·
· Score: 2
IA-64 boxes are going to have a workstation-PROM-like system as a replacement for the BIOS, called EFI. It can read FAT filesystems, run its own programs to do fdisk, format etc. I'm not sure how extensible it is, to read other file systems etc, but it's certainly a huge step up from the BIOS.
Actually, I believe Mandrake no longer uses pgcc because of the instability (someone correct me if I'm wrong). If pgcc barfs on you during compile, that's one thing. If it causes wrong answers or segfaults during program runtime, that's completely another (in response to another poster).
Your comments about gcc tho are pretty much on the mark, although I was under the impression that on x86 gcc was a decent optimizer.
When I've dealt with the cross-haired pointing devices, they've been called 'pucks,' which is unfortunately less deterministic now since the imac mice tend to be called pucks as well.
Re:Let's plunder it for parts
on
AtheOS
·
· Score: 2
My understanding is that Linux based its TCP/IP stack off of a BSD, so this sort of "bolting on" has happened before.
This is a very popular piece of information but it's simply not true. The Linux TCP/IP stack has one or two snippets of BSD code in it (like the VJ Header compression for CSLIP) but was basically written from the ground up. This is why it's exposed many bugs in other operating systems - most OSes have stacks which *are* based off the BSD stack and thus places where it differed from the RFCs were never found.
Asides from that, watching DVDs on a computer monitor means that you don't have to go through the aweful NTSC system and you basically get a progressive scan output, something available only on very high end players and TVs. Unfortunately of course, many people have TVs which are signifigantly larger than their monitors...
Having worked with said SDK, the compilers are certainly available, but the current state of Windows on IA64 is a joke. Most of the management tools don't work, just getting the latest beta installed took 4 tries since the installer keeps crashing and the promised 32 bit compatibility is, for us at least, far from good. What's particularly disappointing is that Windows doesn't seem to have advanced much since the last beta we got months ago. They don't even have a self-hosting compiler yet which makes development a severe PITA. I don't know how Linux stacks up against this yet, but what's out there for Windows right now doesn't really qualify as what I would call 'usable.' At least the latest beta lets you make shortcuts (trying to do so on the last one would crash explorer). So I guess it all depends on what you would define as a 'release' (although as I said, I have no idea what the state of the Linux Itanium world is, it's very possibel I wouldn't qualify it as a 'release' either).
Re:GNU Banned in (some) Fortune 500 companies?
on
Motif's Not Dead
·
· Score: 2
The GPL is extremely misunderstood in many places. People think that if you modify it in-house, you need to distribute your changes. People think that if you use [tool X] which is GPL then your software has to be GPLed as well. etc etc.
They might also mean "Legal ramifications" as in "there's noone to sue."
Say your LILO configuration gets messed up and it doesn't have any bootable images when you reboot. What do you do? You start trying to find a boot disk, because you're up the creek. With GRUB, since it can read the filesystem directly, all you have to start doing is hunting through your fs looking for a kernel image. A more appropriate analogy would be that using LILO is like choosing a car WITHOUT dials even if that option didn't cost you anything.
LILO sucks, try GRUB. GRUB lets you boot from arbitrary kernel images, has a nice menu and doesn't need to be rerun after every kernel install. It works with *BSD, HURD, and maybe other OSes as well.
GRUB was being maintained for a while by Erich Boleyn and, as I remember it, was released as "stable." Recently the GNU people took it over since Erich didn't have time to work on it, and they're probably bringing it up to snuff with features they want.
I agree with other posters tho...GRUB is so nice there's really little reason to still use LILO.
I don't run BSD, but a typical problem with writing disk images is that dd writes in 512 byte chunks by default which is decidedly non-optimal. Try something like
dd if=foo.img of=/dev/fd0 bs=18k
18kb is the size of one track on a 1.44MB floppy, so writing one track at a time should keep the drive busy and reduce the number of seeks etc it has to do. (Of course you probably have to adjust the device name etc etc)
DVDs already have more resolution in them than a normal TV can display. Maybe VHS can't do HDTV, but saying that the source detail "isn't there" in movies is silly. If your eyes can't tell the difference even between DVD and VHS, you should probably start wearing glasses.
The question is easy ("How can I make video look better?"). When the answer (HDTV/broadcasting) actually gets here is a bit trickier.
The source detail is definitely there, so far we simply lack the tools to view it.
Don't think so. From the xanim homepage: I have contacted Sorenson about licensing their codec. They responded that Apple won't allow them to license it to others. It's currently fashionable to think of Apple as the anti-Microsoft, and thus the enemy of my enemy is my friend. Unfortunately, I see little evidence that that's the case.
Hey now, I'd never work *with* databases, but working *in* a database can be quite neat - in many ways it's somewhat like working in an operating system since you handle so many things (paging, data storage etc) at a low level.
What good is a fast transfer rate if you can only hang two devices off it anyhow? Adaptec won't be worried until IDE doesn't limit you to 2 drives on a 14" cable. I mean, even given "theoretical" limits approaching 30MB/sec for some fast drives, the fast is that under real world conditions you'll have difficulty pulling much more than 10MB/sec. Seems kindof like putting racing wheels on a Yugo: the wheels aren't what makes the car go faster, although if you have the speed, they help.
Background: I started Linux using Slackware 1.0, then moved to Redhat 2.0 and then Debian 2.2, so I've been around a bit.
The charges I see levelled most often at other distros (ie Redhat) generally come down to two things: 1. It's too easy to use/is too big, you don't learn 2. It's too unstable. When I started using Slackware, (1) was certainly a complaint many people who were using SLS or MCC levelled against Slackware. As for (2), I remember the days when smail as shipped with Slackware couldn't deliver to MX addresses, when g++ shipped with the wrong path for its headers compiled in and a dozen other problems. So, it hardly seems like bugs are something Redhat has a monopoly on. How do you view these "problems?" You've made backhanded comments about Redhat being unstable before, do you think the charges levelled against other distros are fair? Do you think that these days Slackware *is* stable (even if it wasn't) and has the "right" amount of stuff in it (even if people 6 or 7 years ago disagreed and thought it was too big)? How much difference do you think there really is between using one distro or the other?
"So much longer"? Try maybe 2 years (if that) Redhat's 1.x releases had code names (ie "Mother's Day" release, "Halloween" release etc). I didn't use it back then, but as I understand it, these were NOT beta versions. They then went to Redhat 2.0 which was ELF and started using version numbers.
You can debate whether Redhat increases version numbers too fast, but they've never skipped a number. The fact that you're not even aware of Redhat before 4.x simply exposes what a newbie _you_ are (speaking as someone who started Linux with Slackware 1.0).
ksh is actually quite servicable in the absense of a better one, as long as you apply the right magic to your.shrc or whatnot. To get some decent command line editting do a 'set -o emacs', to get the arrow keys etc to work alias __A=`/bin/echo "\020"` # Up alias __B=`/bin/echo "\016"` # Down alias __C=`/bin/echo "\006"` # Right alias __D=`/bin/echo "\002"` # Left alias __H=`/bin/echo "\001"` # Home alias __p=`/bin/echo "\004"` # Delete alias __q=`/bin/echo "\005"` # End alias __z=`/bin/echo "\017"` # Clear (The previous works on Solaris, it might need some tweaking for different forms of echo) Unfortunately, I don't know of an easy way to get TAB to do filename completion (the default is ESC ESC) Would I rather use ksh than bash? No. But, there are a lot of times when getting ksh to work nicely is easier than getting bash onto the machine in question.
The reference implementations of Kerberos 4 & 5 are available under a BSD-style license, so there's nothing wrong with what Microsoft has done, even if they do use Kerberos code in Windows. (I'm not sure if they've said they use any MIT code or if they did a ground-up implementation based on the specs)
Slashdot Mirror
IA-64 boxes are going to have a workstation-PROM-like system as a replacement for the BIOS, called EFI. It can read FAT filesystems, run its own programs to do fdisk, format etc. I'm not sure how extensible it is, to read other file systems etc, but it's certainly a huge step up from the BIOS.
Actually, I believe Mandrake no longer uses pgcc because of the instability (someone correct me if I'm wrong). If pgcc barfs on you during compile, that's one thing. If it causes wrong answers or segfaults during program runtime, that's completely another (in response to another poster).
Your comments about gcc tho are pretty much on the mark, although I was under the impression that on x86 gcc was a decent optimizer.
When I've dealt with the cross-haired pointing devices, they've been called 'pucks,' which is unfortunately less deterministic now since the imac mice tend to be called pucks as well.
My understanding is that Linux based its TCP/IP stack off of a BSD, so this sort of "bolting on" has happened before.
This is a very popular piece of information but it's simply not true. The Linux TCP/IP stack has one or two snippets of BSD code in it (like the VJ Header compression for CSLIP) but was basically written from the ground up. This is why it's exposed many bugs in other operating systems - most OSes have stacks which *are* based off the BSD stack and thus places where it differed from the RFCs were never found.
Asides from that, watching DVDs on a computer monitor means that you don't have to go through the aweful NTSC system and you basically get a progressive scan output, something available only on very high end players and TVs. Unfortunately of course, many people have TVs which are signifigantly larger than their monitors...
Having worked with said SDK, the compilers are certainly available, but the current state of Windows on IA64 is a joke. Most of the management tools don't work, just getting the latest beta installed took 4 tries since the installer keeps crashing and the promised 32 bit compatibility is, for us at least, far from good. What's particularly disappointing is that Windows doesn't seem to have advanced much since the last beta we got months ago. They don't even have a self-hosting compiler yet which makes development a severe PITA. I don't know how Linux stacks up against this yet, but what's out there for Windows right now doesn't really qualify as what I would call 'usable.' At least the latest beta lets you make shortcuts (trying to do so on the last one would crash explorer). So I guess it all depends on what you would define as a 'release' (although as I said, I have no idea what the state of the Linux Itanium world is, it's very possibel I wouldn't qualify it as a 'release' either).
The GPL is extremely misunderstood in many places. People think that if you modify it in-house, you need to distribute your changes. People think that if you use [tool X] which is GPL then your software has to be GPLed as well. etc etc.
They might also mean "Legal ramifications" as in "there's noone to sue."
Say your LILO configuration gets messed up and it doesn't have any bootable images when you reboot. What do you do? You start trying to find a boot disk, because you're up the creek. With GRUB, since it can read the filesystem directly, all you have to start doing is hunting through your fs looking for a kernel image. A more appropriate analogy would be that using LILO is like choosing a car WITHOUT dials even if that option didn't cost you anything.
LILO sucks, try GRUB. GRUB lets you boot from arbitrary kernel images, has a nice menu and doesn't need to be rerun after every kernel install. It works with *BSD, HURD, and maybe other OSes as well.
GRUB was being maintained for a while by Erich Boleyn and, as I remember it, was released as "stable." Recently the GNU people took it over since Erich didn't have time to work on it, and they're probably bringing it up to snuff with features they want.
I agree with other posters tho...GRUB is so nice there's really little reason to still use LILO.
I don't run BSD, but a typical problem with writing disk images is that dd writes in 512 byte chunks by default which is decidedly non-optimal. Try something like
dd if=foo.img of=/dev/fd0 bs=18k
18kb is the size of one track on a 1.44MB floppy, so writing one track at a time should keep the drive busy and reduce the number of seeks etc it has to do. (Of course you probably have to adjust the device name etc etc)
DVDs already have more resolution in them than a normal TV can display. Maybe VHS can't do HDTV, but saying that the source detail "isn't there" in movies is silly. If your eyes can't tell the difference even between DVD and VHS, you should probably start wearing glasses.
The question is easy ("How can I make video look better?"). When the answer (HDTV/broadcasting) actually gets here is a bit trickier.
The source detail is definitely there, so far we simply lack the tools to view it.
Don't think so. From the xanim homepage:
I have contacted Sorenson about licensing their codec. They responded that Apple won't allow them to license it to others.
It's currently fashionable to think of Apple as the anti-Microsoft, and thus the enemy of my enemy is my friend. Unfortunately, I see little evidence that that's the case.
Hey now, I'd never work *with* databases, but working *in* a database can be quite neat - in many ways it's somewhat like working in an operating system since you handle so many things (paging, data storage etc) at a low level.
BZZZZT, thanks for playing.
Mach was microkernel from Mach 3 on.
eh? Isn't OS X based on Next which is based on Mach 2.5 which isn't micro-kernel based? Or did they port up to Mach 4?
Not arguing that point, just sick of people saying "why can't everything get installed in /usr/local like it wants to be by default."
The Linux filesystem standard states that nothing the distro installs should go in /usr/local. Makes sense if you think about it.
What good is a fast transfer rate if you can only hang two devices off it anyhow? Adaptec won't be worried until IDE doesn't limit you to 2 drives on a 14" cable. I mean, even given "theoretical" limits approaching 30MB/sec for some fast drives, the fast is that under real world conditions you'll have difficulty pulling much more than 10MB/sec. Seems kindof like putting racing wheels on a Yugo: the wheels aren't what makes the car go faster, although if you have the speed, they help.
Background: I started Linux using Slackware 1.0, then moved to Redhat 2.0 and then Debian 2.2, so I've been around a bit.
The charges I see levelled most often at other distros (ie Redhat) generally come down to two things:
1. It's too easy to use/is too big, you don't learn
2. It's too unstable.
When I started using Slackware, (1) was certainly a complaint many people who were using SLS or MCC levelled against Slackware. As for (2), I remember the days when smail as shipped with Slackware couldn't deliver to MX addresses, when g++ shipped with the wrong path for its headers compiled in and a dozen other problems. So, it hardly seems like bugs are something Redhat has a monopoly on.
How do you view these "problems?" You've made backhanded comments about Redhat being unstable before, do you think the charges levelled against other distros are fair? Do you think that these days Slackware *is* stable (even if it wasn't) and has the "right" amount of stuff in it (even if people 6 or 7 years ago disagreed and thought it was too big)? How much difference do you think there really is between using one distro or the other?
"So much longer"? Try maybe 2 years (if that) Redhat's 1.x releases had code names (ie "Mother's Day" release, "Halloween" release etc). I didn't use it back then, but as I understand it, these were NOT beta versions. They then went to Redhat 2.0 which was ELF and started using version numbers.
You can debate whether Redhat increases version numbers too fast, but they've never skipped a number. The fact that you're not even aware of Redhat before 4.x simply exposes what a newbie _you_ are (speaking as someone who started Linux with Slackware 1.0).
ksh actually already has much of what you would consider to be readline support. See my other comment for info on how to enable it.
ksh is actually quite servicable in the absense of a better one, as long as you apply the right magic to your .shrc or whatnot. To get some decent command line editting do a 'set -o emacs', to get the arrow keys etc to work
alias __A=`/bin/echo "\020"` # Up
alias __B=`/bin/echo "\016"` # Down
alias __C=`/bin/echo "\006"` # Right
alias __D=`/bin/echo "\002"` # Left
alias __H=`/bin/echo "\001"` # Home
alias __p=`/bin/echo "\004"` # Delete
alias __q=`/bin/echo "\005"` # End
alias __z=`/bin/echo "\017"` # Clear
(The previous works on Solaris, it might need some tweaking for different forms of echo) Unfortunately, I don't know of an easy way to get TAB to do filename completion (the default is ESC ESC) Would I rather use ksh than bash? No. But, there are a lot of times when getting ksh to work nicely is easier than getting bash onto the machine in question.
The reference implementations of Kerberos 4 & 5 are available under a BSD-style license, so there's nothing wrong with what Microsoft has done, even if they do use Kerberos code in Windows. (I'm not sure if they've said they use any MIT code or if they did a ground-up implementation based on the specs)
You can get some more info on this issue in the Kerberos FAQ