That sounds eerily familiar... I think most admins that need a stable production system probably end up doing about the same thing!
I was spoiled starting out as a Windows programmer. I hate to say it, but Windows has the best attitude towards backwards compatibility of any mainstream platform I've seen. System APIs are preseved, bug-for-bug, *forever*. If I ship or buy a Windows package today, I'm virtually guaranteed it will run on any Windows platform years into the future. Whereas Linux binaries age like meat in the summer sun.
Perhaps one day a Linux or BSD vendor will get their act together and offer a truly stable system (in the sense of minor upgrades not routinely breaking everything). This will probably require a lot of effort to modularize the various component packages and strictly enforce versioning of interfaces. (Debian seems furthest ahead - e.g. they understand that unstable libraries need a unqie API version for each and every release, regardless of whether the original authors care to provide one)
The LSB seemed like it was intended to move forward in this direction, but instead it just seems to have codified the existing (poor) situation. RedHat provided a pretty good solution (100% compatibility within major releases) but with the discontinuation of support for their low-end distros, Linux software vendors are left with no clear standard target system.
I have a feeling this is caused by either a window manager bug or graphics context switching.
A recent version of icewm had a bug that would cause it to busy-wait nearly 100% of the time. I kind of doubt you were using icewm though.
With the newer OpenGL cards there is a BIG difference between running one OpenGL app and running more than one. Performance scales poorly because the graphics card must context switch between them. Perhaps another window somewhere on your system had created an OpenGL context. Or, perhaps some app was doing a lot of 2D X drawing. (little things like 'top' process monitors, clocks, and MP3 players can add up...)
You could also solve the resizing flicker with a window manager standard - if the WM knows (via some kind of interrogation message) that the app wants a synchronous window border, then they can post events to each other to synch up their painting. This could be incorporated into the existing WM standards (ICCM or whatever).
I think a separate "manager" process will always be needed, so that you can get rid of windows when the application running them goes into a long calculation or infinite loop. I would be happy with window border drawing in the app, plus very rudimentary window dragging/resizing implemented in the X server itself (saving a round-trip as well).
The cool thing about drag-resizing on Windows is that it's synchronous, as opposed to X where the window border doesn't wait for the app contents to draw, which means no matter how fast your machine is, you will ALWAYS see artifacts when resizing on X.
(perhaps Mac OS did this first though, I'm not sure)
Ray tracing does seem to have some on-paper theoretical advantages, but I've always found that it's a render time killer for my scenes. While the asymptotic running time of ray tracing is good, the coefficient is so much higher that "polygon splatting" has won every time so far.
You also need to consider that the O(log N) figure for ray tracing does not include the cost of building a ray-acceleration data structure, and it also assumes the entire scene fits in RAM. Polygon splatting is O(N), but the coefficient is much smaller, and RAM requirements are much less. Depending on how your scene is organized, and how much you can cull, you may be able to get more like O(log N) behavior from a scanline renderer.
Also, if you think of "N" not as geometry elements but as output pixels, ray tracing is O(N^2) whereas I claim that scanline rendering scales at somewhat less than O(N^2), because you don't need to shade each and every screen-space sample. (look at how PRMan works for an example of this).
I would REALLY like to see a standard for finding phone numbers via DNS. We use DNS precisely because it's too hard to remember the correct up-to-date IP address of the services we want. Why should we continue to remember peoples' phone numbers? Now that many cell phones are internet-connected, you should be able to type in e.g. "call.joesmith.com" and the phone should do a DNS lookup to get the phone number.
Maybe this has been done already? Or is the "typing in" the problem?
Not sure about Canadian law, but in the US a patent certainly can prevent use of the patented product.
From USPTO.GOV: "The patent grant excludes others from making, using, or selling the invention in the United States."
For all of you screaming that this decision is unfair, read the article carefully. The farmer knew he had acquired the patented seeds and re-used them without a license. And if you don't think plants should be patentable, fine, but then this crop wouldn't exist in the first place. The fact that other farmers pay to use the patented seeds proves that they have a positive economic value.
I am a little annoyed at how Apple never admits that its software actually contains bugs.
Very often I see messages like:
"This Final Cut Pro update 'improves compatibility' with XYZ files" (i.e. it doesn't CRASH when loading them anymore)
or
"This update 'reduces the chance of an issue' with XYZ hardware" (i.e. it doesn't CORRUPT your FILESYSTEM anymore)
I do appreciate the frequent updates, I just wish Apple wouldn't beat around the bush. They use words like "improve" and "issue" to conceal the fact that their product had a major flaw. Probably their lawyers figured they could get sued if they ever admitted any kind of fault. (heck, I wanted to sue them when they shipped me a system with a DOA hard disk and refused to take it back:)
Microsoft realized early on that in order for their platform to dominate, they MUST recruit as many third-party developers as possible. This is one of the main reasons, if not THE main reason, that Windows acquired its huge desktop market share. (make fun of Steve Ballmer for his "DEVELOPERS! DEVELOPERS! DEVELOPERS!" monkey dance if you want, but that's why he's a billionaire). Microsoft bends over backwards to help developers. They give away excellent development tools with excellent documentation and support, just so that you'll write Windows programs. They nearly kill themselves checking backwards compatibility with every Windows release, just to make sure your poorly-written Windows program doesn't break when Windows XP comes out.
Apple seems to care about its users somewhat, but not at all about its developers. There just isn't the same level of outreach nor the same "developers come first" attitude as Microsoft. And not nearly as much care about compatibility. e.g. how many OSX programs broke with the OSX 1.2 and 1.3 updates?
Both companies offer excellent APIs that are specific to their platforms (e.g. DirectX on Windows and Cocoa on Mac). But Microsoft has an advantage here. If you write your program to use Windows-exclusive APIs, you still have 90% of the potential market. But if you use Apple-specific APIs, you cut yourself down to 10%. THAT is why.NET and Java are attracting developers, and Cocoa is not.
Any rational desktop software company will develop for Windows first, and then, if it seems worthwhile, they'll make a Mac port. There is a small market for Mac-only stuff but I don't think it's a reasonable business strategy to support ONLY the Mac. For one thing, Apple has a habit of shipping free products by surprise that demolish the market for an established Mac vendor. (how'd you like to be a Mac-only calendar/email application developer the day after iCal and Mail came out? or MetroWerks' Mac team after Xcode?). This is outright developer-hostile behavior.
Arbitrary audio delay would make a nice feature for high-end digital audio decoders.
I had not thought about speed of sound before; it looks like just standing at the back of a large room can put you 1 frame out of sync. So much for those sound design people that think they need to sync everything to the quarter-frame:)
Cineon as I've used it is 10 bits. Doesn't seem like much, but the logarithmic encoding is very efficient (moreso than a gamma encoding). Also most film images have a great deal of grain, which tends to hide quantization artifacts.
It's worse than that. Binary C++ libraries won't even link between GCC and VC++ because of different name mangling, and I think the calling conventions are different too. Currently there is no way to mix C++ code on Windows between different compilers at other than source code level. (well I think Intel's compiler is compatible with Microsoft's)
I'm not sure what one can do about._filenames. These are used by OSX to store resource forks on filesystems that do not support them directly. All but the most modern Mac OSX applications depend heavily on resource forks. e.g. if you take a Final Cut Pro project file, and delete its corresponding._file, Final Cut will no longer be able to open the file (I found this out the hard way:).
Given that OSX must support many legacy applications that rely on resource forks, I see no other option for Apple. Perhaps they could offer a mount option to disable._ resource forks, in the hope that most applications would eventually switch to using conventional files and directories. But I wouldn't hold my breath; most companies with Mac OS-based products would rather stick with the Carbon compatibility layer than re-write all their filesystem code to use the POSIX APIs.
Depending on your point of view, resource forks are either the best or the worst thing ever to happen to filesystems:)
Also, there is an issue with NFS file locking on OSX - it uses unusually large cookies, which are rejected by some NFS servers (including Linux 2.4.x, at least until recently). You may need to patch NFS servers if you are getting file lock problems with OSX. (don't know about samba though)
I'm also interested to hear if anyone else is getting rather poor NFS read/write performance. My G4 gets only about 50% the performance of Linux clients (on the same gigabit network with the same Linux server). And finally, OSX's automount daemon seems to drop NFS mounts and then not be able to get them back. The only way around this I've found is to reboot. (or mount the NFS shares manually, but it seems automount is strongly preferred on OSX)
Changing the desktop resolution is certainly not as useful as it once was. (the main reason I used to change it a lot was for games or video playback that wouldn't go full speed unless I dropped down to 640x480). Today I can only think of one reason, which is hooking up a laptop to an external monitor or projection system (how many times have you seen someone hook up a modern laptop to a projector, and have to fiddle the resolution down to 1024x768 to get anything on the screen?:)
NTSC/HDTV encoding may be another reason, but most consumer-oriented video encoders resample the framebuffer anyway, so it doesn't matter for them.
I've had a good experience with a Dell PowerConnect hub (the 8- or 16-port model, I forget which). It was quite inexpensive and claims to support Jumbo Frames (however I haven't actually gotten this to work; when I enlarge the frame size on Linux it loses the connection). Oh, and I had to disable one default feature on the hub (tree-spanning something or other) to get it to work.
For clients I use Intel gigabit cards (the 64-bit PCI "server" model). I wouldn't skimp here since indications are that cheap gigabit cards don't have any hope of getting wire speed. NFS file copies max out at 20-30MB/sec, but I know that is limited by my server's disk array. I did a test for raw network bandwidth (just sending zero bytes as fast as possible) and got around 60-80MB/sec.
Everything is connected to my existing Cat-5 cable with no problems. This includes several Linux systems, one Mac and one Windows PC.
I will caution you not to expect anything like gigabit wire speeds with typical clients. My Mac G4 in particular seems to have trouble getting good bandwidth (I think the problem is either the network stack or NFS client).
If anyone has a success story with jumbo frames, I'd love to hear about it. The only references I could find are for mega-dollar Cisco/Foundry type equipment.
I still don't get it. If you want DV resolution video at 3MB/sec, why not use DV? The DV codec runs faster too.
The only things I can think of are 1) really high resolution, like 2048x1536 frames (I haven't tested it this high, maybe it beats JPEG) or 2) >8 bits per component. (although I think if you need >8 bits you'd also want a lossless codec).
One thing that hasn't been clear in the news releases is that Pixlet is a lossy codec. At first I thought it was lossless but on testing it is lossy (quite lossy actually). It is useful for previewing high-res animations, but not for rendering final elements.
I'm not really sure what the point of Pixlet is, since JPEG is "good enough" for most previewing needs. Perhaps somebody is using it for >8 bits per component?
Do you think that someone should tell Astrobiology Magazine that 30 kph is about 18 mph? That's almost double the mph that they give the rover credit for.
Well, with the exchange rate as it is, kilometers just don't buy you the same miles they used to.
Thanks for the correction. (I did a Google search to confirm my recollection of MIPS NT being big-endian but didn't find the answer)
I find it interesting that my post, whose factual content is entirely false, got modded up to +5 Insightful... I think there's too much "mod inflation" at Slashdot.
NT 4 ran on MIPS in big-endian mode I believe. So the OS itself is probably endian-safe.
It's interesting to see that we've reached a point where most OSes and software is portable enough to run on most 32- and 64-bit systems with little modification. (and where MS can switch CPU architectures without Xbox developers throwing a fit). A long way from the day of writing everything in assembly.
I agree that "installation" should go away. Especially for operating systems - why bother with a complex installer when you can just copy a filesystem image?
On Windows the majority of well-written installers are single self-extracting.exe's or.msi's.
With OSX you get a.dmg if you are lucky (and a.dmg.gz,.sit, or.dmg.sit if you are not). You double-click the.dmg and it mounts a virtual disk. You run the program inside. You try to unmount the virtual disk but it won't let you because it is in use. Then you close the program and unmount the disk. You still have to throw away the original.dmg and the archive (if it came in one).
It kind of sucks to have your OSX desktop cluttered with foo.dmg.sit, foo.dmg, and Foo, just for one program.
Slashdot Mirror
That sounds eerily familiar... I think most admins that need a stable production system probably end up doing about the same thing!
I was spoiled starting out as a Windows programmer. I hate to say it, but Windows has the best attitude towards backwards compatibility of any mainstream platform I've seen. System APIs are preseved, bug-for-bug, *forever*. If I ship or buy a Windows package today, I'm virtually guaranteed it will run on any Windows platform years into the future. Whereas Linux binaries age like meat in the summer sun.
Perhaps one day a Linux or BSD vendor will get their act together and offer a truly stable system (in the sense of minor upgrades not routinely breaking everything). This will probably require a lot of effort to modularize the various component packages and strictly enforce versioning of interfaces. (Debian seems furthest ahead - e.g. they understand that unstable libraries need a unqie API version for each and every release, regardless of whether the original authors care to provide one)
The LSB seemed like it was intended to move forward in this direction, but instead it just seems to have codified the existing (poor) situation. RedHat provided a pretty good solution (100% compatibility within major releases) but with the discontinuation of support for their low-end distros, Linux software vendors are left with no clear standard target system.
I have a feeling this is caused by either a window manager bug or graphics context switching.
A recent version of icewm had a bug that would cause it to busy-wait nearly 100% of the time. I kind of doubt you were using icewm though.
With the newer OpenGL cards there is a BIG difference between running one OpenGL app and running more than one. Performance scales poorly because the graphics card must context switch between them. Perhaps another window somewhere on your system had created an OpenGL context. Or, perhaps some app was doing a lot of 2D X drawing. (little things like 'top' process monitors, clocks, and MP3 players can add up...)
You could also solve the resizing flicker with a window manager standard - if the WM knows (via some kind of interrogation message) that the app wants a synchronous window border, then they can post events to each other to synch up their painting. This could be incorporated into the existing WM standards (ICCM or whatever).
I think a separate "manager" process will always be needed, so that you can get rid of windows when the application running them goes into a long calculation or infinite loop. I would be happy with window border drawing in the app, plus very rudimentary window dragging/resizing implemented in the X server itself (saving a round-trip as well).
The cool thing about drag-resizing on Windows is that it's synchronous, as opposed to X where the window border doesn't wait for the app contents to draw, which means no matter how fast your machine is, you will ALWAYS see artifacts when resizing on X.
(perhaps Mac OS did this first though, I'm not sure)
Ray tracing does seem to have some on-paper theoretical advantages, but I've always found that it's a render time killer for my scenes. While the asymptotic running time of ray tracing is good, the coefficient is so much higher that "polygon splatting" has won every time so far.
You also need to consider that the O(log N) figure for ray tracing does not include the cost of building a ray-acceleration data structure, and it also assumes the entire scene fits in RAM. Polygon splatting is O(N), but the coefficient is much smaller, and RAM requirements are much less. Depending on how your scene is organized, and how much you can cull, you may be able to get more like O(log N) behavior from a scanline renderer.
Also, if you think of "N" not as geometry elements but as output pixels, ray tracing is O(N^2) whereas I claim that scanline rendering scales at somewhat less than O(N^2), because you don't need to shade each and every screen-space sample. (look at how PRMan works for an example of this).
One would hope the French are a little better at building bridges than airports...
I would REALLY like to see a standard for finding phone numbers via DNS. We use DNS precisely because it's too hard to remember the correct up-to-date IP address of the services we want. Why should we continue to remember peoples' phone numbers? Now that many cell phones are internet-connected, you should be able to type in e.g. "call.joesmith.com" and the phone should do a DNS lookup to get the phone number.
Maybe this has been done already? Or is the "typing in" the problem?
Not sure about Canadian law, but in the US a patent certainly can prevent use of the patented product.
From USPTO.GOV:
"The patent grant excludes others from making, using, or selling the invention in the United States."
For all of you screaming that this decision is unfair, read the article carefully. The farmer knew he had acquired the patented seeds and re-used them without a license. And if you don't think plants should be patentable, fine, but then this crop wouldn't exist in the first place. The fact that other farmers pay to use the patented seeds proves that they have a positive economic value.
I am a little annoyed at how Apple never admits that its software actually contains bugs.
:)
Very often I see messages like:
"This Final Cut Pro update 'improves compatibility' with XYZ files"
(i.e. it doesn't CRASH when loading them anymore)
or
"This update 'reduces the chance of an issue' with XYZ hardware"
(i.e. it doesn't CORRUPT your FILESYSTEM anymore)
I do appreciate the frequent updates, I just wish Apple wouldn't beat around the bush. They use words like "improve" and "issue" to conceal the fact that their product had a major flaw. Probably their lawyers figured they could get sued if they ever admitted any kind of fault. (heck, I wanted to sue them when they shipped me a system with a DOA hard disk and refused to take it back
Microsoft realized early on that in order for their platform to dominate, they MUST recruit as many third-party developers as possible. This is one of the main reasons, if not THE main reason, that Windows acquired its huge desktop market share. (make fun of Steve Ballmer for his "DEVELOPERS! DEVELOPERS! DEVELOPERS!" monkey dance if you want, but that's why he's a billionaire). Microsoft bends over backwards to help developers. They give away excellent development tools with excellent documentation and support, just so that you'll write Windows programs. They nearly kill themselves checking backwards compatibility with every Windows release, just to make sure your poorly-written Windows program doesn't break when Windows XP comes out.
.NET and Java are attracting developers, and Cocoa is not.
Apple seems to care about its users somewhat, but not at all about its developers. There just isn't the same level of outreach nor the same "developers come first" attitude as Microsoft. And not nearly as much care about compatibility. e.g. how many OSX programs broke with the OSX 1.2 and 1.3 updates?
Both companies offer excellent APIs that are specific to their platforms (e.g. DirectX on Windows and Cocoa on Mac). But Microsoft has an advantage here. If you write your program to use Windows-exclusive APIs, you still have 90% of the potential market. But if you use Apple-specific APIs, you cut yourself down to 10%. THAT is why
Any rational desktop software company will develop for Windows first, and then, if it seems worthwhile, they'll make a Mac port. There is a small market for Mac-only stuff but I don't think it's a reasonable business strategy to support ONLY the Mac. For one thing, Apple has a habit of shipping free products by surprise that demolish the market for an established Mac vendor. (how'd you like to be a Mac-only calendar/email application developer the day after iCal and Mail came out? or MetroWerks' Mac team after Xcode?). This is outright developer-hostile behavior.
Arbitrary audio delay would make a nice feature for high-end digital audio decoders.
:)
I had not thought about speed of sound before; it looks like just standing at the back of a large room can put you 1 frame out of sync. So much for those sound design people that think they need to sync everything to the quarter-frame
Cineon as I've used it is 10 bits. Doesn't seem like much, but the logarithmic encoding is very efficient (moreso than a gamma encoding). Also most film images have a great deal of grain, which tends to hide quantization artifacts.
It's worse than that. Binary C++ libraries won't even link between GCC and VC++ because of different name mangling, and I think the calling conventions are different too. Currently there is no way to mix C++ code on Windows between different compilers at other than source code level. (well I think Intel's compiler is compatible with Microsoft's)
I'm not sure what one can do about ._filenames. These are used by OSX to store resource forks on filesystems that do not support them directly. All but the most modern Mac OSX applications depend heavily on resource forks. e.g. if you take a Final Cut Pro project file, and delete its corresponding ._file, Final Cut will no longer be able to open the file (I found this out the hard way :).
._ resource forks, in the hope that most applications would eventually switch to using conventional files and directories. But I wouldn't hold my breath; most companies with Mac OS-based products would rather stick with the Carbon compatibility layer than re-write all their filesystem code to use the POSIX APIs.
:)
Given that OSX must support many legacy applications that rely on resource forks, I see no other option for Apple. Perhaps they could offer a mount option to disable
Depending on your point of view, resource forks are either the best or the worst thing ever to happen to filesystems
Also, there is an issue with NFS file locking on OSX - it uses unusually large cookies, which are rejected by some NFS servers (including Linux 2.4.x, at least until recently). You may need to patch NFS servers if you are getting file lock problems with OSX. (don't know about samba though)
I'm also interested to hear if anyone else is getting rather poor NFS read/write performance. My G4 gets only about 50% the performance of Linux clients (on the same gigabit network with the same Linux server). And finally, OSX's automount daemon seems to drop NFS mounts and then not be able to get them back. The only way around this I've found is to reboot. (or mount the NFS shares manually, but it seems automount is strongly preferred on OSX)
Changing the desktop resolution is certainly not as useful as it once was. (the main reason I used to change it a lot was for games or video playback that wouldn't go full speed unless I dropped down to 640x480). Today I can only think of one reason, which is hooking up a laptop to an external monitor or projection system (how many times have you seen someone hook up a modern laptop to a projector, and have to fiddle the resolution down to 1024x768 to get anything on the screen? :)
NTSC/HDTV encoding may be another reason, but most consumer-oriented video encoders resample the framebuffer anyway, so it doesn't matter for them.
I've had a good experience with a Dell PowerConnect hub (the 8- or 16-port model, I forget which). It was quite inexpensive and claims to support Jumbo Frames (however I haven't actually gotten this to work; when I enlarge the frame size on Linux it loses the connection). Oh, and I had to disable one default feature on the hub (tree-spanning something or other) to get it to work.
For clients I use Intel gigabit cards (the 64-bit PCI "server" model). I wouldn't skimp here since indications are that cheap gigabit cards don't have any hope of getting wire speed. NFS file copies max out at 20-30MB/sec, but I know that is limited by my server's disk array. I did a test for raw network bandwidth (just sending zero bytes as fast as possible) and got around 60-80MB/sec.
Everything is connected to my existing Cat-5 cable with no problems. This includes several Linux systems, one Mac and one Windows PC.
I will caution you not to expect anything like gigabit wire speeds with typical clients. My Mac G4 in particular seems to have trouble getting good bandwidth (I think the problem is either the network stack or NFS client).
If anyone has a success story with jumbo frames, I'd love to hear about it. The only references I could find are for mega-dollar Cisco/Foundry type equipment.
I still don't get it. If you want DV resolution video at 3MB/sec, why not use DV? The DV codec runs faster too.
The only things I can think of are 1) really high resolution, like 2048x1536 frames (I haven't tested it this high, maybe it beats JPEG) or 2) >8 bits per component. (although I think if you need >8 bits you'd also want a lossless codec).
One thing that hasn't been clear in the news releases is that Pixlet is a lossy codec. At first I thought it was lossless but on testing it is lossy (quite lossy actually). It is useful for previewing high-res animations, but not for rendering final elements.
I'm not really sure what the point of Pixlet is, since JPEG is "good enough" for most previewing needs. Perhaps somebody is using it for >8 bits per component?
PRMan for the Mac (OSX/G5) has been in public testing for a while.
Do you think that someone should tell Astrobiology Magazine that 30 kph is about 18 mph? That's almost double the mph that they give the rover credit for.
Well, with the exchange rate as it is, kilometers just don't buy you the same miles they used to.
Thanks for the correction. (I did a Google search to confirm my recollection of MIPS NT being big-endian but didn't find the answer)
I find it interesting that my post, whose factual content is entirely false, got modded up to +5 Insightful... I think there's too much "mod inflation" at Slashdot.
Charging license fees for object code is not the only way to make money from software.
NT 4 ran on MIPS in big-endian mode I believe. So the OS itself is probably endian-safe.
It's interesting to see that we've reached a point where most OSes and software is portable enough to run on most 32- and 64-bit systems with little modification. (and where MS can switch CPU architectures without Xbox developers throwing a fit). A long way from the day of writing everything in assembly.
I agree that "installation" should go away. Especially for operating systems - why bother with a complex installer when you can just copy a filesystem image?
On Windows the majority of well-written installers are single self-extracting .exe's or .msi's.
.dmg if you are lucky (and a .dmg.gz, .sit, or .dmg.sit if you are not). You double-click the .dmg and it mounts a virtual disk. You run the program inside. You try to unmount the virtual disk but it won't let you because it is in use. Then you close the program and unmount the disk. You still have to throw away the original .dmg and the archive (if it came in one).
With OSX you get a
It kind of sucks to have your OSX desktop cluttered with foo.dmg.sit, foo.dmg, and Foo, just for one program.