(Disclaimer: I wrote the UDF support in FreeBSD, but I have offer no other legal or technical advice)
As usual, the/. headline is vague and misleading. This doesn't look like it applies to CD recording itself, or even packet writing. Instead it looks like it applies to the VAT in the UDF >= 1.5 spec. Basically, the VAT is a sector remapping table. Since CD-R media can only be recorded sequentially, and obviously cannot overwrite existing sectors/packats, the VAT makes this linear recording look like a normal random access filesystem. The VAT is not used on CD/DVD RW media so those are probably clear, and definitely is not used in iso9660 volumes. So at worst this means that the UDF spec becomes encumbered when using the VAT. I'm not clear on whether the OSTA, IEEE, and/or ECMA bodies knew about this patent when they ratified the various specs that contribute towards UDF, but this definitely looks to be an abuse by the patent holder.
Worst case scenario is that this patent is upheld and Roxio (and others like Nero) start paying royalties. The Linux distributors might have to remove VAT support from their kernels. Commercial OS vendors would have to decide on whether to license it or remove it. I'm not sure if DVD mastering software will be affected since the VAT is not part of the UDF 1.0 spec. mkisofs might be affected also if it impliments VAT. Whether the OSTA committee responds with an alternative remains to be seen. But, it's not the end of the world. Like I said, I don't think that this has any bearing on CD-R's that are recorded with traditional iso9660 filesystems. Supporting write-once media and VAT is a PITA anyways, so this gives me a good excuse to not care about it in my implimentation =-)
I'll take a minor leap of faith and guess that this flaimbait was authored by either Bill Huey or Jeffrey Hsu. And oh my god, this really hurts my feelings!
I'm still somewhat surprised that this got committed now, shouldn't 5.2 be released Really Soon Now? This looks like something that ought to be tested in -CURRENT for a good while.
This is of course a very valid concern. It should be noted, however, that this was the last phase in the overall change. The 'heavy lifting' parts were done months ago (creating/rescue, moving libraries to/lib and/libexec). It also had been extensively tested by many developers, and was already an optional switch when building world. In the end, we decided that a dynamic root filesystem was the future of 5.x, and that the 5.3 cycle was already overbooked with significant changes. We still have nearly a month before the release date of 5.2 to iron out any bugs. So after some final testing for a few days last week, I asked Gordon to Throw The Switch.
Look at RedHat's price structure (sorry, can't find a good URL) and offerings. It sure has some similarities with MSWindows, and I'm sure it's not an accidental coincidence. They seem to agree with Microsoft that dividing the OS into segments and having a tiered price model is a viable strategy. I tend to think that Fedora is just an 'appeasement' effort and that dropping the Pro line from the consumer channel (i.e. Fry's, Best Buy) is a serious mistake, but we'll see how well this all works.
I can't find the upgrade on the Apple site and I'm not near my PowerMac. So the big question for me is whether this fixes the NV17 problem. It's getting pretty painful to run my machine on reduced RAM.
If you're talking about the Belkin F5U109, the lack of an OSX driver isn't a loss. I wrote a driver for it for FreeBSD (umct.c), and I can honestly say that the device is a smelly piece of poo. It drops charaters when switching bps rates, mis-marks its USB endpoints, and doesn't come even close to supporting real RS-232 line discipline. I originally bought it for my wife's TiBook with the intent of writing an OSX driver for it, but I'm not going to bother anymore. I'd suggest looking elsewhere. It's sad because the F5U103 is nearly identical but isn't nearly as brain-damaged.
Sorry, I *did* mean 'high'. Here's some information I found:
Yeah, it looks like their PCI-X slots are 3.3V only. Not a big surprise. Still, I'm looking at my Big Pile O PCI Cards and very few of them are keyed for 5V only. The ones that are 5V-only aren't the kind of thing that I would put into a $2K machine (do I really want to put a RealTek 10BaseT card in there? Or a Mylex DAC960 UltraWide RAID? Ugh!). YMMV.
" not only will this affect performance, but it will also make it impossible to recover a server if you accidentally delete/usr,"
What wasn't mentioned in the write-up is that/rescue contains statically-link versions of the tools that one would need to recover from problems. It might not be able to recover a deleted filesystem, but if you're trouncing careless around like that then there are plenty of other ways to shoot your feet off too.
Thank goodness they still don't know if you went to the bathroom for a break or to the fridge.
I think the point that we all are missing is that we should be watching TV for the ads and taking our breaks during the filler (a.k.a. the actual show). At least, that's the way to be a good consumer.
Well something must have changed in recent psutils, because now 'ps' correctly collapses threads within processes when they are not active (I assume). When my site gets a hit, I see the threads expand, and once the request is served, they are collapsed back under a single process line.
The support that I added was to make the kernel return info on all threads unless it is told not to. I then changed ps(1) to tell the kernel to not return all threads unless the user specifies the -H option. I didn't modify top as it is vendor code and I haven't gotten around to tackling it yet.
As for your observation, remember that in KSE/SA the kernel only knows about the threads that have blocked inside of it and the per-CPU scheduler activation (i.e. execution context) that it supplies to the userland scheduler (UTS). It has no knowledge of threads that the UTS creates that stay in userland. Sooo.... it is likely that you saw a thread that blocked in the kernel waiting for the socket, and then left the kernel once the socket woke up.
Don't forget that there is also the libthr 1:1 library. That creates a kernel thread for every user thread. Since the kernel knows about every thread, ps and top will show each thread also.
I'm incredibly pleased with all of this. I finally got around to reading the SA paper last month, and it's very cool to see KSE start to realize its potential. 5.2 and 5.3 will be very exciting releases.
Dude, give the editors a break on this one. I purposely made the subject of my announcement abiguous in order to attract attention. Which sounds better, "New Bootloader!", or "My attempt to enhance the user experience with 100 lines of Forth". Anyways, this is just a start. Hopefully I'll have some time to do cool stuff, like have the loader scan for kernels and present you with a choice, control the serial console, etc. While GRUB is cool and all, editing configuration files is still a turn-off to many people.
Look in/usr/share/examples/etc/make.conf. It was moved there about a year ago. The reasoning was that it didn't actually contain defaults (like/etc/defaults/rc.conf does), but just usage examples.
Finally a voice of freaking reason on this subject! For those of you who haven't been in charge of a DARPA contract, there are very specific rules on how money can be spent. There is some speculation that Theo's hack-a-thon violated these rules, so the 'Work Stop Order' came down as a response. It most likely has nothing to do with terrorists, open source, anti-war statements, or beer. Good god, people! All of this attention is NOT going to benefit these kinds of projects in the future!
Well, it appears from most of the comments here that no one has actually test driven the program yet. Well, I just fired it up on my shiny new NX70V, and I got to say that I'm quite impressed. I already own a 48GX and 49G, so I had no moral delimmas with installing those rom images. I don't own a 48SX, so I can't comment on it. Anyways:
The speed is very impressive. I ran some of the TEACH examples on the 48GX mode and they fly. It's easily 2-3 times faster than the real hardware. Of course my hardware is StrongArm based, so I wonder how well the DragonBall hardware will work. Time to go dig out my wife's N760.
Button layout for the 48GX was nearly identical to the real hardware. Button layout for the 49G was a little strange, with the arrow keys being shoved off to the left side and the 6 function keys that used to be next to them compressed from 2 rows of three to 1 row of 6. Not a big deal, but tough to get used to.
As impressive as it is, I still prefer the feel of the real 48GX hardware. That machine was designed back when HP knew how engineers operated. Of course, I hate the 49G key layout and rubberized buttons, but that's a bikeshed of a different color. Anyways, even with the 320x480 screen, the buttons are a bit too small to comfortably work by finger-touch. Using the stylus is fine, but not like having the real buttons.
I haven't tried any 3rd-party programs. From reading the documentation I'd guess that things written in SysRPL and and UserRPL will probably work fine, but I wonder if ASM stuff will also work.
In all, I'm highly impressed with this, though it will take a few weeks to see if I treat it like a toy or a real calc.
Bologna. Its not beta and its considered stable. Gee, ss the release manager for 5.0 and the author of the 5-STABLE roadmap doc, I kinda have to beg to differ. 5.0 is not what we consider 'stable' in the same sense of the 4-STABLE label that the 4.x series has. You have to account for the two definitions of 'stable'. One means 'runtime stability' where you likely to have good uptimes under heavy loads. The other is 'API stability' where you can expect programming interfaces and algorithms within the system to remain consistent. 5.0 really doesn't meet the first definition well, though it is fine as a desktop OS. It fails miserably at the second definition, as there is a significant amount of change going on in the kernel to satisfy the first definition and support some new features.
5.0 was released because we wanted to get all of the new features that were in the tree out to the audience that had been waiting 3 years for them. We tried to be careful to emphasize that while 5.0 should make a fine desktop OS, it really isn't appropiate for a production server yet. The upcoming 5.1 release is looking to be a significant improvement on the runtime stability front, though that api stability is still going to be in flux for a bit. Most likely 5.2 will be branded as '5-STABLE' and hence satisfy both definitions of 'stable', and that should happen this fall.
Seriously, though, I'd eventually like to see some real world performance specs of Hammer running in 32 bit mode [...]
Benchmarks will come in time. Right now everyone that has a Hammer system is under NDA from AMD. Think about it, if everyone was posting performance numbers months before Hammer was ready for introduction, that would give Intel plenty of time to come up with some sort of response. When April 23 comes and the chip is officially released, I suspect that a ton of performance numbers will be released within a few seconds.
As for the 32-bit-on-64-bit problem, remember that the amd64 architecture is just an extension on ia32, much like ia32 was an extension of the 16-bit stuff. Code either uses the wider registers or it doesn't. The real fear is that 64-bit code won't perform as fast as 32-bit code, since 64-bit pointers/integers/etc means less efficient cache usage.
Slashdot Mirror
Do you have a reference for this?
(Disclaimer: I wrote the UDF support in FreeBSD, but I have offer no other legal or technical advice)
/. headline is vague and misleading. This doesn't look like it applies to CD recording itself, or even packet writing. Instead it looks like it applies to the VAT in the UDF >= 1.5 spec. Basically, the VAT is a sector remapping table. Since CD-R media can only be recorded sequentially, and obviously cannot overwrite existing sectors/packats, the VAT makes this linear recording look like a normal random access filesystem. The VAT is not used on CD/DVD RW media so those are probably clear, and definitely is not used in iso9660 volumes. So at worst this means that the UDF spec becomes encumbered when using the VAT. I'm not clear on whether the OSTA, IEEE, and/or ECMA bodies knew about this patent when they ratified the various specs that contribute towards UDF, but this definitely looks to be an abuse by the patent holder.
As usual, the
Worst case scenario is that this patent is upheld and Roxio (and others like Nero) start paying royalties. The Linux distributors might have to remove VAT support from their kernels. Commercial OS vendors would have to decide on whether to license it or remove it. I'm not sure if DVD mastering software will be affected since the VAT is not part of the UDF 1.0 spec. mkisofs might be affected also if it impliments VAT. Whether the OSTA committee responds with an alternative remains to be seen. But, it's not the end of the world. Like I said, I don't think that this has any bearing on CD-R's that are recorded with traditional iso9660 filesystems. Supporting write-once media and VAT is a PITA anyways, so this gives me a good excuse to not care about it in my implimentation =-)
I'll take a minor leap of faith and guess that this flaimbait was authored by either Bill Huey or Jeffrey Hsu. And oh my god, this really hurts my feelings!
I'm still somewhat surprised that this got committed now, shouldn't 5.2 be released Really Soon Now? This looks like something that ought to be tested in -CURRENT for a good while.
/rescue, moving libraries to /lib and /libexec). It also had been extensively tested by many developers, and was already an optional switch when building world.
This is of course a very valid concern. It should be noted, however, that this was the last phase in the overall change. The 'heavy lifting' parts were done months ago (creating
In the end, we decided that a dynamic root filesystem was the future of 5.x, and that the 5.3 cycle was already overbooked with significant changes. We still have nearly a month before the release date of 5.2 to iron out any bugs. So after some final testing for a few days last week, I asked Gordon to Throw The Switch.
Look at RedHat's price structure (sorry, can't find a good URL) and offerings. It sure has some similarities with MSWindows, and I'm sure it's not an accidental coincidence. They seem to agree with Microsoft that dividing the OS into segments and having a tiered price model is a viable strategy. I tend to think that Fedora is just an 'appeasement' effort and that dropping the Pro line from the consumer channel (i.e. Fry's, Best Buy) is a serious mistake, but we'll see how well this all works.
I can't find the upgrade on the Apple site and I'm not near my PowerMac. So the big question for me is whether this fixes the NV17 problem. It's getting pretty painful to run my machine on reduced RAM.
If you're talking about the Belkin F5U109, the lack of an OSX driver isn't a loss. I wrote a driver for it for FreeBSD (umct.c), and I can honestly say that the device is a smelly piece of poo. It drops charaters when switching bps rates, mis-marks its USB endpoints, and doesn't come even close to supporting real RS-232 line discipline.
I originally bought it for my wife's TiBook with the intent of writing an OSX driver for it, but I'm not going to bother anymore. I'd suggest looking elsewhere. It's sad because the F5U103 is nearly identical but isn't nearly as brain-damaged.
I like the headline. Kudos.
Sorry, I *did* mean 'high'. Here's some information I found:
Yeah, it looks like their PCI-X slots are 3.3V only. Not a big surprise. Still, I'm looking at my Big Pile O PCI Cards and very few of them are keyed for 5V only. The ones that are 5V-only aren't the kind of thing that I would put into a $2K machine (do I really want to put a RealTek 10BaseT card in there? Or a Mylex DAC960 UltraWide RAID? Ugh!). YMMV.
The G4 is compatible with my low voltage PCI cards. The G5 isn't.
Can you please provide your reference for this claim? I find this quite hard to believe. Maybe you meant 'high' and not 'low'?
" not only will this affect performance, but it will also make it impossible to recover a server if you accidentally delete /usr,"
/rescue contains statically-link versions of the tools that one would need to recover from problems. It might not be able to recover a deleted filesystem, but if you're trouncing careless around like that then there are plenty of other ways to shoot your feet off too.
What wasn't mentioned in the write-up is that
Thank goodness they still don't know if you went to the bathroom for a break or to the fridge.
I think the point that we all are missing is that we should be watching TV for the ads and taking our breaks during the filler (a.k.a. the actual show). At least, that's the way to be a good consumer.
Well something must have changed in recent psutils, because now 'ps' correctly collapses threads within processes when they are not active (I assume). When my site gets a hit, I see the threads expand, and once the request is served, they are collapsed back under a single process line.
The support that I added was to make the kernel return info on all threads unless it is told not to. I then changed ps(1) to tell the kernel to not return all threads unless the user specifies the -H option. I didn't modify top as it is vendor code and I haven't gotten around to tackling it yet.
As for your observation, remember that in KSE/SA the kernel only knows about the threads that have blocked inside of it and the per-CPU scheduler activation (i.e. execution context) that it supplies to the userland scheduler (UTS). It has no knowledge of threads that the UTS creates that stay in userland. Sooo.... it is likely that you saw a thread that blocked in the kernel waiting for the socket, and then left the kernel once the socket woke up.
Don't forget that there is also the libthr 1:1 library. That creates a kernel thread for every user thread. Since the kernel knows about every thread, ps and top will show each thread also.
I'm incredibly pleased with all of this. I finally got around to reading the SA paper last month, and it's very cool to see KSE start to realize its potential. 5.2 and 5.3 will be very exciting releases.
You need to add either SCHED_4BSD or SCHED_ULE to your kernel config. This is documented in the /usr/src/UPDATING file.
Dude, give the editors a break on this one. I purposely made the subject of my announcement abiguous in order to attract attention. Which sounds better, "New Bootloader!", or "My attempt to enhance the user experience with 100 lines of Forth".
Anyways, this is just a start. Hopefully I'll have some time to do cool stuff, like have the loader scan for kernels and present you with a choice, control the serial console, etc. While GRUB is cool and all, editing configuration files is still a turn-off to many people.
Look in /usr/share/examples/etc/make.conf. It was moved there about a year ago. The reasoning was that it didn't actually contain defaults (like /etc/defaults/rc.conf does), but just usage examples.
Finally a voice of freaking reason on this subject!
For those of you who haven't been in charge of a DARPA contract, there are very specific rules on how money can be spent. There is some speculation that Theo's hack-a-thon violated these rules, so the 'Work Stop Order' came down as a response. It most likely has nothing to do with terrorists, open source, anti-war statements, or beer.
Good god, people! All of this attention is NOT going to benefit these kinds of projects in the future!
The ServerWorks Grand Champion series and the Intel 75xx series of chipsets both support >4GB. The no-name Taiwanese brands from Fry's usually don't. Each serves a different market.
In all, I'm highly impressed with this, though it will take a few weeks to see if I treat it like a toy or a real calc.
Dude, chill and see my other response to you. I appreciate your enthusiasm, but you should take a step back and listen to what people are telling you.
Bologna. Its not beta and its considered stable.
Gee, ss the release manager for 5.0 and the author of the 5-STABLE roadmap doc, I kinda have to beg to differ. 5.0 is not what we consider 'stable' in the same sense of the 4-STABLE label that the 4.x series has. You have to account for the two definitions of 'stable'. One means 'runtime stability' where you likely to have good uptimes under heavy loads. The other is 'API stability' where you can expect programming interfaces and algorithms within the system to remain consistent. 5.0 really doesn't meet the first definition well, though it is fine as a desktop OS. It fails miserably at the second definition, as there is a significant amount of change going on in the kernel to satisfy the first definition and support some new features.
5.0 was released because we wanted to get all of the new features that were in the tree out to the audience that had been waiting 3 years for them. We tried to be careful to emphasize that while 5.0 should make a fine desktop OS, it really isn't appropiate for a production server yet. The upcoming 5.1 release is looking to be a significant improvement on the runtime stability front, though that api stability is still going to be in flux for a bit. Most likely 5.2 will be branded as '5-STABLE' and hence satisfy both definitions of 'stable', and that should happen this fall.
Seriously, though, I'd eventually like to see some real world performance specs of Hammer running in 32 bit mode [...]
Benchmarks will come in time. Right now everyone that has a Hammer system is under NDA from AMD. Think about it, if everyone was posting performance numbers months before Hammer was ready for introduction, that would give Intel plenty of time to come up with some sort of response. When April 23 comes and the chip is officially released, I suspect that a ton of performance numbers will be released within a few seconds.
As for the 32-bit-on-64-bit problem, remember that the amd64 architecture is just an extension on ia32, much like ia32 was an extension of the 16-bit stuff. Code either uses the wider registers or it doesn't. The real fear is that 64-bit code won't perform as fast as 32-bit code, since 64-bit pointers/integers/etc means less efficient cache usage.
- FreeBSD 5-CURRENT
- Dell Inspirion 8200
- nVidia GeForce4 440 Go with nVidia drivers
- linux_base port (RedHat 7.1)
- linux_glx port
I symlinked libGLU.so.3 to libGLU.so.1 to pacify the binary, but that may be part of the problem. If anyone has any ideas, please let me know!What can I say.... the article showed up in a Slashbox, and I didn't look close enough at the byline. =-)
Hey team: no penguins in your game, okay?
Amen brother!