I hear that people are saying it would be difficult to port Windows XP to RISC chips (and new 64bit arch).
Windows XP already runs on 64 bit hardware. MS have been supplying developers (like myself) with 64 bit SDKs for at least 6 months, and migration information (i.e. recommendations for writing portable code) for at least 12 months. NVidia have been shipping 64 bit video drivers for about 6 months as well...
Under Windows, they introduce data marshalling issues that have to be accounted for in user code -- not just in the modules which implement interpreters for that user code
What do you mean by "marshalling" in this context? Maybe I've misread something but I understood marshalling to be about converting data from one internal format to a wire-transmission format and back - the classic example being converting host-endian to/from network-endian byte format. Do you just mean locking?
JBuilder is a terrible example; it's buggy, slow, it's got all the hallmarks of a Java GUI application (the flickering, the multiple-redraw-even-if-I-don't-need-to), and to make things worse it tries to emulate MS DevStudio.NET features like Intellisense, and gets them WRONG.
For example, it pops up a completion menu, or an error, just like DevStudio - the difference is that DevStudio NEVER puts that window over what I'm typing, and takes it away again on the next keystroke. JBuilder obscures what you're typing with it, and then only removes it when you take your hands off the keyboard and mouse-click somewhere else. Arrgh!
And yes, this is the latest version on a 2GHz machine; it still sucks harder than a Dyson.
People avoid AMD because the majority of motherboard chipsets are not very good; anything made by Via is junk, with either CPU, and no-one seems to make good high-end AMD motherboards. The manufacturers are all marketing AMD hardware at the spotty gamer who's just going to wreck it trying to overclock his CPU anyway...
I'd buy AMD if I thought the motherboard might actually have been through some sort of quality control, but my experiences to date have been pretty bad, whereas I've never had a bad Intel-chipset board since the days of my first 8 MB 486DX33.
With reference to the JFK thread, I recently watched a documentary of an investigation into a fatal "shooting" at a rifle range. Some kid was sat inside a metal hut (an indoor pistol range) when suddenly he fell to the floor, dead, from a single bullet wound to the head. To cut a long story short, he was killed by a pistol round from:
a modified handgun which double-fired on the recoil
held by a person on a completely different range
stood in the one place where the wildly off-target second shot could pass through the 1 inch cap between an earth mound and a baffle
before entering the indoor range through a broom cupboard and deflecting upwards
grazing a cardboard ceiling tile and deflecting back down instead of just passing through
before finally hitting the victim
The chain of probabilities was incredible. It took days of 3D computer simulation coupled with ballistics analysis to work out what had happened - yet it happened and someone died as a result. The guy that fired the pistol didn't even realise his gun had fired twice.
Back to school for you! IR and micro/radio waves are LONGER wavelength, LOWER frequency than the visible spectrum. You'd store LESS information on a disk using IR lasers, not more. If anything, UV is the way to go, followed by gamma rays (except you really wouldn't want a cobalt-60 radioactive source in your DVD drive), and the detector would be pretty impractical too...
Bombadil was, effectively, the "true-neutral" of Tolkien's middle earth - it's hinted that he's as powerful as the other greats (Gandalf, Elrond) but refuses to participate, and is unaffected by the One Ring. Perhaps reading some of Tolkien's less well-known books (Leaf & Niggle, for example) might explain more.
(and yes, the Harvard Lampoon version is _very_ funny!)
And furthermore, if you're in a congested cell, emergency calls will kick people off to free up bandwidth for your call. Can't remember if it's last-on, first-off or some other scheme.
It gets entertaining if the cell is full of people making 112 calls, though;-)
This is exactly like those Soccer Moms who wipe every surface with low-grade antibiotics and insist the doctor give their rugrat antibiotics for their every cold. It's utterly useless, and the only result is to produce stronger and tougher viri.
Please explain how antibiotics affect virus particles in any way at all. For bonus points, attach an annotated diagram of a bacteriophage. Write on both sides of the paper. Either way up boy, I'm not bothered.
Any businessman with a fractional clue could have figured out how to use that information to build a profitable business.
Oh really? Collecting marketing data isn't much use when you can't actually sell a product to anyone because they've already downloaded bootleg copies of the studio master tapes.
A 400 MHz ARM-derived processor should be able to handle pretty much anything your might want to do, short of playing Unreal Tournament on it!
Interesting that the article alludes to "production difficulties" with the XScale. Anyone know what did Intel manage to do to screw up StrongARM? I know they had problems with USB on early SA-1100s, but the article is talking about CPU performance issues...
Companies should be bound by law to maintain DTDs and XML converters for their proprietary formats.
And what happens if that DTD simply contains one binary element, "DocFileData"? I think you'd need to specify things in immense detail - perhaps to the extent of writing the DTD yourself!
That would take care of the content loss every damn time M$ changes its fuckin' formats.
What content loss would that be? I run Office XP, and I have no problem reading legacy documents I or other people have created, going back to Office 4 on Windows 3.11. If you need backwards compatibility, check out the MS Office Converter Pack, on the Resource Kit, or here. There's even a 16 bit version if you're still running Windows 3.1.
We're not. I was just not familiar with the details of Ogg Vorbis. Anyway, that's precisely my point. Ogg is the bitstream format, Vorbis is the codec, and separating the two can be helpful when patents are involved and cross-platform compatibility is an issue.
Arguably, Sorenson is a codec, not a format - Quicktime is a format, just as MS AVI is a format and Windows Media 8 is a codec. Some other file types are more difficult to classify, but MS stuff in particular seems to adhere to this sort of division - consider WAV files, for example. The RIFF format coverns how the data is stored, but says nothing about the actual data - that can be MP3, uLaw, OGG...
I think it's helpful to make this distinction because the formats can easily be made public domain, whereas the codecs are usually subject to patents and/or require licensing.
File interchange becomes much simpler if you stop worrying about codecs, and concentrate on supporting formats - Linux tools for video could read & write the AVI format (just interleaved RIFF chunks) but either use a free codec, or none at all, without creating yet another video file standard.
MS Word is a different problem - although RTF is the preferred interchange format anyway. Certainly my partner (who occasionally works as a freelance proof-reader) uses RTF extensively with her clients instead of Word native format. The RTF v1.6 spec. is available in the MSDN, and includes sample reader & writer source code.
Well, your PDF breaks Acrobat Reader 5.01 - page down from the title page gives "There was an error processing a page. The page contents object has the wrong type." The table of contents doesn't seem to start until page 5. Corrupt PDF?
It's your choice - as developer you have the option of released a non-GPL kernel driver (assuming you don't use GPL code, of course!) as a module. See the desktop NVidia graphics card drivers, for example.
I agree with you 100%. The GNU tool chain is not a no-brainer on non-x86 platforms, presumably because the projects rely on testing feedback to find and fix bugs.
For my first (PPC-based) project where I tried to build a toolchain from scratch I had real problems finding a mutually compatible set of binutils, gcc & glibc that could successfully compile QT Embedded (i.e. C++).
I think this presents a real problem for business. The source code is freely available, but some feature or other doesn't work on your chosen platform without extra patches (gcc in particular, but also glibc). The appropriate set patches is hard to find - Redhat and Montavista know about them, but they ain't telling because their business model effectively revolves around knowing what you need to do to make the software work. So, "Open Source" becomes "Closed Knowledge" because at the end of the day, everyone needs to make money and if the source is free, then charge for the knowledge / expertise.
This makes support an interesting proposition - you get companies who will help you, but only by doling out the information a piece at a time - because in their marketplace, knowledge is power.
Now, Montevista supply (excellent, patched and working) toolchains for all their supported platforms for "free" (or rather the cost of downloading 3 ISO images). By doing so, they effectively try to lock you in to their support model (which is around $10,000 a year for a single point-of-contact), especially when you discover that the range of BSPs they ship is pretty small, and expensive to add to - you're on your own if you're platform isn't on the list.
In the end, it's no better than proprietry solutions - just different.
I see a lot of Windows plugins using DirectX / COM, but what does the Mac use? Do VST have their own cross-platform plugin format, or do they use COM wrappers on Windows?
Interesting. Anyone got any hard data on latency through the kernel & OSS / Alsa drivers? I'd like to see a comparison with ASIO / WDM drivers on Win2K, and whatever-macs-use as well.
How might one go about measuring latency in the same way across totally different platforms? I would be happy to do some tests.
If I create a product and need an embedded OS, and I have the capabilities in-house to do whatever configuration and programming is necessary, then embedded Linux can cost $0.00 per unit (hey kids - that's means it's free!), compaired to $x for a commercial OS
Yes, and if you don't have the in-house expertise to write the missing drivers, fix the bugs and handle the many and varied forked kernels for embedded apps (like, practically one for each major architecture), it's going to cost you an arm and a leg.
The software may be free, but sinec it won't run on your platform without considerable effort, it costs you more in the end. I've consulted on embedded linux projects and in every case the extra hassle and design constraints were just not worth it.
For example, the embedded PowerPC kernel is effectively forked - patches don't get fed back into the main kernel tree so you have to go and get development sources with BitKeeper for PPC-specific fixes. These include things like an endian-specific bug in the serial UART driver for the 2.2 kernel that was trivial but didn't get fixed until 2.4.
Scratch another 2 days at $God-only-knows-how-much / day while we figure out that you also don't get full RS-232 handshake in 2.2, and in fact the early UART code is useless. Pity our framebuffer display driver code (from Epson) is specific to 2.2. Scratch another week while we port it to 2.4 because someone thought it'd be cool to change all the function signatures in the framebuffer code...
You see what I mean? All the while the project is getting later and later, the bills are mounting up and the boss is starting to think "I wish I'd chosen a supported, validated embedded OS and just paid for it up front". It's death by a thousand cuts, if you've got to ship a product.
Hungarian notation is a bit more involved that that, and is actually extremely useful when not taken to extremes. That bit of kernel documentation is opinion, not some God-given truth handed down from the prophets to the great unwashed.
For example, Hungarian can encompass scope in the variable name, which makes (a small number of) file & project scope globals just about bearable.
The real win is that it makes pointers obvious - and in a language that encourages pointer arithmetic, that's invaluable for easy reading of code.
I've used a variant of Hungarian for Java, that uses "m" for member, "a" for function parameter, "s" for class static. It works pretty well, too.
Try it, you might like it. It's all about personal preference, and I find Hungarian-style prefixs plus InterCapitalisation more readable than some all_lower_case alternative.
Oh, and "//" is a valid single line comment in ISO C '99. HTH. HAND.
Eventually I imagine desktops will want 64 bits as well. I've already got 1.5GB in the workstation I'm typing this on.
Increased address space doesn't necessarily require the jump to a full 64 bit architecture. Some Intel chips already support 36 bit addresses, while having 32 bit word length. It's a bodge, because pointers are still 32 bit (think back to 16 bit DOS and segmented memory architecture) but it's already there. You can have 16 GB in your desktop, if you can afford it.
Microsoft seems to be taking the view that SIP is the way to go and is down playing H.323.
Ick. H.323 is a dog to operate through NAT. If both parties are using NAT, you have problems getting one side to call the other. I've been able to call out from behind a NAT router to a modem user, but not accept calls coming the other way. It looks like SIP also needs a proxy of some sort.
For a useful comparison check out this H323 vs SIPcomparison. Looks like SIP is a lot simpler but less interoperable with things like PSTN.
Really, these days there's no excuse for protocols that hide IP information in the packet data (that's FTP, H.323, and a ton of others).
Slashdot Mirror
Windows XP already runs on 64 bit hardware. MS have been supplying developers (like myself) with 64 bit SDKs for at least 6 months, and migration information (i.e. recommendations for writing portable code) for at least 12 months. NVidia have been shipping 64 bit video drivers for about 6 months as well...
Jon
Absolutely. Now PLEASE can we have a "-5, Factually Incorrect" moderation option? There's so much crap gets modded up it's untrue.
Jon.
What do you mean by "marshalling" in this context? Maybe I've misread something but I understood marshalling to be about converting data from one internal format to a wire-transmission format and back - the classic example being converting host-endian to/from network-endian byte format. Do you just mean locking?
Jon
For example, it pops up a completion menu, or an error, just like DevStudio - the difference is that DevStudio NEVER puts that window over what I'm typing, and takes it away again on the next keystroke. JBuilder obscures what you're typing with it, and then only removes it when you take your hands off the keyboard and mouse-click somewhere else. Arrgh!
And yes, this is the latest version on a 2GHz machine; it still sucks harder than a Dyson.
Jon.
I'd buy AMD if I thought the motherboard might actually have been through some sort of quality control, but my experiences to date have been pretty bad, whereas I've never had a bad Intel-chipset board since the days of my first 8 MB 486DX33.
Jon.
The chain of probabilities was incredible. It took days of 3D computer simulation coupled with ballistics analysis to work out what had happened - yet it happened and someone died as a result. The guy that fired the pistol didn't even realise his gun had fired twice.
Jon.
(and yes, the Harvard Lampoon version is _very_ funny!)
Jon
It gets entertaining if the cell is full of people making 112 calls, though ;-)
Jon.
Please explain how antibiotics affect virus particles in any way at all. For bonus points, attach an annotated diagram of a bacteriophage. Write on both sides of the paper. Either way up boy, I'm not bothered.
Any businessman with a fractional clue could have figured out how to use that information to build a profitable business.
Oh really? Collecting marketing data isn't much use when you can't actually sell a product to anyone because they've already downloaded bootleg copies of the studio master tapes.
Jon.
So does the e740 - looks like these features are part of the XScaleCPU & support chipset.
Jon.
Interesting that the article alludes to "production difficulties" with the XScale. Anyone know what did Intel manage to do to screw up StrongARM? I know they had problems with USB on early SA-1100s, but the article is talking about CPU performance issues...
Jon.
And what happens if that DTD simply contains one binary element, "DocFileData"? I think you'd need to specify things in immense detail - perhaps to the extent of writing the DTD yourself!
That would take care of the content loss every damn time M$ changes its fuckin' formats.
What content loss would that be? I run Office XP, and I have no problem reading legacy documents I or other people have created, going back to Office 4 on Windows 3.11. If you need backwards compatibility, check out the MS Office Converter Pack, on the Resource Kit, or here. There's even a 16 bit version if you're still running Windows 3.1.
Jon.
We're not. I was just not familiar with the details of Ogg Vorbis. Anyway, that's precisely my point. Ogg is the bitstream format, Vorbis is the codec, and separating the two can be helpful when patents are involved and cross-platform compatibility is an issue.
I think it's helpful to make this distinction because the formats can easily be made public domain, whereas the codecs are usually subject to patents and/or require licensing.
File interchange becomes much simpler if you stop worrying about codecs, and concentrate on supporting formats - Linux tools for video could read & write the AVI format (just interleaved RIFF chunks) but either use a free codec, or none at all, without creating yet another video file standard.
MS Word is a different problem - although RTF is the preferred interchange format anyway. Certainly my partner (who occasionally works as a freelance proof-reader) uses RTF extensively with her clients instead of Word native format. The RTF v1.6 spec. is available in the MSDN, and includes sample reader & writer source code.
Jon.
Jon
Jon.
For my first (PPC-based) project where I tried to build a toolchain from scratch I had real problems finding a mutually compatible set of binutils, gcc & glibc that could successfully compile QT Embedded (i.e. C++).
I think this presents a real problem for business. The source code is freely available, but some feature or other doesn't work on your chosen platform without extra patches (gcc in particular, but also glibc). The appropriate set patches is hard to find - Redhat and Montavista know about them, but they ain't telling because their business model effectively revolves around knowing what you need to do to make the software work. So, "Open Source" becomes "Closed Knowledge" because at the end of the day, everyone needs to make money and if the source is free, then charge for the knowledge / expertise.
This makes support an interesting proposition - you get companies who will help you, but only by doling out the information a piece at a time - because in their marketplace, knowledge is power.
Now, Montevista supply (excellent, patched and working) toolchains for all their supported platforms for "free" (or rather the cost of downloading 3 ISO images). By doing so, they effectively try to lock you in to their support model (which is around $10,000 a year for a single point-of-contact), especially when you discover that the range of BSPs they ship is pretty small, and expensive to add to - you're on your own if you're platform isn't on the list.
In the end, it's no better than proprietry solutions - just different.
Jon
Jon
How might one go about measuring latency in the same way across totally different platforms? I would be happy to do some tests.
Jon.
Yes, and if you don't have the in-house expertise to write the missing drivers, fix the bugs and handle the many and varied forked kernels for embedded apps (like, practically one for each major architecture), it's going to cost you an arm and a leg.
The software may be free, but sinec it won't run on your platform without considerable effort, it costs you more in the end. I've consulted on embedded linux projects and in every case the extra hassle and design constraints were just not worth it.
For example, the embedded PowerPC kernel is effectively forked - patches don't get fed back into the main kernel tree so you have to go and get development sources with BitKeeper for PPC-specific fixes. These include things like an endian-specific bug in the serial UART driver for the 2.2 kernel that was trivial but didn't get fixed until 2.4.
Scratch another 2 days at $God-only-knows-how-much / day while we figure out that you also don't get full RS-232 handshake in 2.2, and in fact the early UART code is useless. Pity our framebuffer display driver code (from Epson) is specific to 2.2. Scratch another week while we port it to 2.4 because someone thought it'd be cool to change all the function signatures in the framebuffer code...
You see what I mean? All the while the project is getting later and later, the bills are mounting up and the boss is starting to think "I wish I'd chosen a supported, validated embedded OS and just paid for it up front". It's death by a thousand cuts, if you've got to ship a product.
Jon
The fact that Sun called their threads "Light Weight Processes" might give you a clue why that might be ;-)
"No, you can't just call fork() and pretend it's a thread!"
Jon.
For example, Hungarian can encompass scope in the variable name, which makes (a small number of) file & project scope globals just about bearable.
The real win is that it makes pointers obvious - and in a language that encourages pointer arithmetic, that's invaluable for easy reading of code.
I've used a variant of Hungarian for Java, that uses "m" for member, "a" for function parameter, "s" for class static. It works pretty well, too.
Try it, you might like it. It's all about personal preference, and I find Hungarian-style prefixs plus InterCapitalisation more readable than some all_lower_case alternative.
Oh, and "//" is a valid single line comment in ISO C '99. HTH. HAND.
Jon.
Increased address space doesn't necessarily require the jump to a full 64 bit architecture. Some Intel chips already support 36 bit addresses, while having 32 bit word length. It's a bodge, because pointers are still 32 bit (think back to 16 bit DOS and segmented memory architecture) but it's already there. You can have 16 GB in your desktop, if you can afford it.
Jon.
Ick. H.323 is a dog to operate through NAT. If both parties are using NAT, you have problems getting one side to call the other. I've been able to call out from behind a NAT router to a modem user, but not accept calls coming the other way. It looks like SIP also needs a proxy of some sort.
For a useful comparison check out this H323 vs SIPcomparison. Looks like SIP is a lot simpler but less interoperable with things like PSTN.
Really, these days there's no excuse for protocols that hide IP information in the packet data (that's FTP, H.323, and a ton of others).
Jon