Hmm... how many of those are features of the protocol, as opposed to features of one or more of the main server implementations?
I can easily understand why they might want to omit offline messages, for example. In addition to the matter of storage (which they're probably not that bothered about) there's the issue that they must then store and forward messages. That may be legally different to a direct "switching" rely or direct user<->user comms.
The gateways are probably a legal thing, and again probably a feature of specific server implementations.
As for file transfers and group chat, I don't get that. I can only imagine that to be client limitations - or do they not work even with 3rd party clients?
To load Windows, GRUB just chain-loads the bootloader on the primary Windows partition (what Windows will use as C: drive). That's actually 16 bit code, even on AMD64.
WinXP 64 bit ed may be different, but your post suggests you're using the basic XP.
If I recall correctly a definition like:
root (hd0,0) chainload +1
should do the trick (adjusting root to match your win32 c: ). I use Fedora, so to be honest it "just works".
*HOWEVER* it sounds like you're trying to boot XP off a secondary disk. If XP thinks that disk is the primary disk (ie you installed XP then rearranged the disks), it'll get really confused when you load its boot sector, and will fail to boot. I don't know if it's an easy thing to fix - I've always just installed windows where I expect it to live (it installs quite happily on a secondary disk).
You might be able to boot the XP cd, run "fixboot" and "fixmbr" from the recovery console, then re-install GRUB from a Linux rescue CD.
Where exactly does socialism come into this? I happen to disagree with you on that (moderation being OK IMO) but anyway... I don't think it's relevant.
Australia is a regulated capitalist economy. Like most of them. Where monopolies cause problems - such as the case of Telstra - or in other cases of market failure, action is taken to address the problem.
In this case, that means forcing Telstra Wholesale to offer access to exchanges and lines at the same prices as it provides them to its retail devision.
Telstra used to be a government department. It was essentially *gifted* the national infrastructure. Don't start me on that. The least it can be expected to do is provide equitable access to that infrastructure.
I strongly suggest you study some economics before saying that free markets are the full solution to the problem. You're looking specifically for "externalities" and "market failure". Note that Telstra is one such instance where the natural free market fails to achieve the capitalist economic goal - efficient distribution of resources - *and* the social goal - equitable distribution of resources.
I also happen to disagree that the alternate delivery approaches you suggest are reasonable alternatives. It is in the interest of consumers to have DSL and dial-up available from a competitive market - that Telstra, left un-checked, would strangle or prevent from by denying access to exchanges and lines. (If you suggest just building another national infrastructure I'll have to laugh at you).
Cable in Australia is not the same as in the US. It is not already laid everywhere. Moreover, guess what - Telstra owns the main Cable network. BPL isn't available here. I'm not convinced it should be. WiFi ISPs are available in some areas, but I'm unconvinced it's a viable alternative to DSL. Ditto CDMA/GSM/3G and other radio technologies. DSL and dial-up are controlled by Telstra by virtue of their control of the infrastructure.
Think about it this way: Telstra is somewhat like "ma bell". Which the US government took action to break the monopoly of, I might add, by rather drastically splitting the company. (I wish we'd do that to Telstra - but into wholesale and retail arms, to eliminate the internal conflict of interest over wholesale access and service).
Anyway, speaking of economics, I have some more study to do.
Synchronous? I'm not sure fibre/ethernet is, actually - and more to the point, I suspect the fact that it's symmetric is more important.
I'm in Australia, and I must say - you folks are lucky by comparison to us, though it *is* getting better here. We have an agency called the ACCC - Australian Competition and Consumer Commission - that's been slowly beating the incumbent telco into shape.
This would be a valid issue - if there was any crime involved.
Spoofing an email, or putting up a fake website, was not a crime last I heard.
Someone might try to take civil action against you if offended (trademark problems; leibel; etc) but the chances are pretty darn good they won't if you're doing it with their permission.
Personally, I think this is an important education tool. Where it becomes a problem is if it goes too far, into "oops! Look! this trojan has been on your system for a week emailing your credit card details to some dodgy site. I guess you should be more careful with your email."
I remember how I was finally able to wake a few people up about the issue of viruses and impersonation in the very early days of mass email worms - not long after the Melissa worm. Direct education attempts had failed with the staff, so I sent an email to all of them that pretended to be our Prime Minister (this is a newspaper) with some... "interesting" content and a date in 2048. The message made clear at the end that it was a fake, and there was nothing inappropriate in the message.
It was remarkable how many people came to me and asked about that - it was clear that it'd managed to get their attention as simply explaining the issue ("the From: address doesn't guarantee that it's from who it says it is") had failed to do.
Despite almost computer illiterate users, we've been unaffected by email worms due to a combination of a paranoid mail gateway and such periodic reminders to users. Things like a.vbs script that pops up a dialog saying "If this had been a malicious script, it could have destroyed all your work and broken your computer" has a profound effect, it seems.
There are gzip accelerator PCI cards available for cases where CPU is an issue. Whether they're cheaper in large clusters than just adding some hosts or getting a bigger pipe, I don't know... but they're another option.
I don't imagine it would be simple - network protocols rarely are.
That said, HTTP is pretty much made for it with its support for `Content-Encoding:', and the clear headers/body separation. You still have to do things like make sure the client understands gzip, of course.
The job would also be vastly simplified by zlib. I'd consider implementing your own gzip compressor pretty extreme when zlib is free and extremely well tested.
I'm not going to make the argument another fellow did (it can't corrupt your disk) 'cos it's not true, though you'd have to be pretty darn unlucky.
The more important point is - you were running Apache as root?! If so, I don't blame your boss. If not, how exactly did it corrupt the disk? I'd be putting my money on an unrelated error (without information to the contrary) personally - early disk failure, etc.
In general, though, firing someone for implementing software they've approved on a production server after testing is stupidity. That's not the sort of place I'd want to work anyway, frankly. He was middle management in a larger company I presume?
mod_gzip is a C program. Like any C program, some types of programming error can cause stack corruption, which can leave unexpected crud on the stack that is then executed by the CPU. It is not impossible that system calls will be part of said crap.
That said, it's not overly likely, and you'd have to be pretty unlucky to have something like that happen even when testing it and having it crash repeatedly.
The more important point is "What? You were running Apache as root?"
It's for exactly this reason that I never, ever "make install" as root. Everything is --prefix'ed to $HOME/apps/$APPNAME and installed as a normal user.
It doesn't help that I hack on build systems, so I have a decent idea just how nasty one could be if desired.
I'm pretty sure they've swapped in the UnixWare kernel, and ported over the useful OpenSewer bits.
UnixWare at least didn't require you to relink (not recompile) the kernel and reboot to change IP address.
I use OpenServer 5.0.5 at work. TCP/IP is an optional extra - it ships on the CDs, but you don't have to install it, and it's not available in the basic version of the OS.
What valid points McBride has give points straight to Sun, something I find immensely amusing.
Most tellingly, I suspect NOBODY uses OpenServer for Internet-exposed hosts. It's used a lot for legacy systems inside the network, but as a public host is going to be pretty darn unusual.
It also has the advantage of having almost no features. sshd - nope. Apache? Only an ancient version from Skunkware, and I'm pretty sure that hasn't been patched.
It's rather harder to hack if it's relying on the protection of another host, and it exposes basically nothing but telnet anyway.
That said, McBride *does* make some good points, but they're the same ones made by Sun before - and Sun, unlike SCO, are the ones to go to if you don't want to use Linux. I'd love to see Sun take him up on his kernel challenge;-)
If building in backdoors is so common, I'm shocked not have heard any major security advisories about compromised backdoors.
Even if they do, it's a heck of a lot better than a/single/ backdoor that'll work across a wide range of devices, and can't just be closed when access to it becomes public knowledge.
While I see what you're getting at and generally agree with you, that's not always true.
You have to pick your "target audience." Do you assume they have a solid understanding of the language and tools (such as a framework/toolkit)? Do you assume they're an expert with them? With a large toolkit, or complex language (think C++ and MFC), especially with a lot of subtelties, it's *NOT* reasonable to assume the reader knows something just because you do.
In an open source C++ project, you might not even want to assume all that much knowledge of C++, to make it easier for people with a C background to follow what's going on and track down a bug.
The following, for example, is C++ that you might see in Qt code that calls out to Python's C API. It's also broken for non-latin-1 text coding, but this is just a sample:
That relies on knowledge of:
- Pointers
- the dynamic_cast<> operator's behaviour, namely that it does a runtime check to see whether `name' can be cast to a Fred* based on inheritance (using RTTI), and returns 0 if it can not be cast.
- That Q_ASSERT is a macro that will check the pointer is not zero (depending on compile time flags, it'll print a warning or abort the program)
- that calls into the Python/C API return NULL when they've set an exception, and if you're going to be returning to Python you should return NULL to propagate the exception. (Otherwise you must PyErr_Print() or PyErr_Clear() it).... and probably lots more. There's no sane way to explain all that. You have to pick your balance of expecting people to use API documentation and know the language, while explaining to them the bits you think need more explanation. It's not easy, given that what needs explaining varies depending on the reader.
After all, this:
<ecode> class Fred(object): pass fredInstance = Fred() def printName(self):
print "I'm Fred!" Fred.printName = printName fredInstance.printName() </ecode>... probably hurts the brain of a programmer used to static languages like C++. It might be best to explain to a Python user, too, since it's not that commonly used. Similarly, if I was going to use recursive template metaprogramming in a C++ program I'd need to explain that in detail, because most C++ programers don't know about it - but I wouldn't expect to have to explain the cast operators.
I also think it's ok if someone looks puzzled by part of your code that's *genuinely* *hard*. Complex algorithms can take a while to understand, for example. There, your *goal* is to make them look like they're thinking hard, rather than have them exclaim "WTF!" or "huh? what the heck is this?".
The reason we don't have supported 3rd party drivers is because Linux doesn't have the market share (yet) to warrant the OEMs supporting us.
Well, part of the reason, anyway. The Linux development process and developers are also indifferent to "out-of-tree" development, and fairly hostile to binary-only drivers. There is no stable API, let alone ABI, and no interest in maintaining one. Additionally, the kernel team are unwilling to accept "OS adaptor" compatibility layers in drivers.
That's not necessarily bad - it brings with it a lot of advantages - but it does mean that supporting Linux is a *LOT* of work for a hardware vendor. The user base must be correspondingly larger for it to be worth their while.
I find this an absolutely critical tool when designing and writing new classes. I don't usually write each method that way, but the overall class structure, the methods, and the members are all written as stubs and commented before any "real" code goes in.
I can't seem to "think it out on paper" but I *can* think it out in words in a header file, and massage that into the shape I want before starting any "real" code.
You make a good point about drivers. It's one I'm pretty sure I've made in response to others before, but it entirely slipped my mind today. We need only look at Darwin/x86 to see what a dismal base they'd be starting from on the driver front.
I'm not really convinced re the rest of your argument. Explicitly beta OS releases (with things like a boot-up message saying "This is a beta-quality demo. The full version of the OS will not run on your PC." might still be useful.
It's all well and good to tell folks to buy the Apple dev kit, until you look at the price tag. It's nothing for a developer who considers the Mac an important platform, but it'll prevent anybody who wants to check it out and see what possibilities there are from trying it out. In fairness, unless a developer has used a cross-platform toolkit like Qt they won't learn much without spending a lot more than that (in time, if nothing else) anyway.
Given the driver issue, I imagine a general release would be out. I still maintain that a XenU version would be very interesting, since only geeks and developers would want to run it anyway, given the most likely limited graphics support and the need for a Linux host OS, but it'd help get them more exposure among linux/UNIX developers.
Knowing this full well it was rather obvious Apple would have to take some sort of action to keep their OS from being widely pirated within days of the first dev kits being delivered.
Why should they? I work on an app that's cross platform - Linux, alpha on Mac OS X and a Win32 port in the works. Having access to the latest Mac OS X for free on my normal desktop without having to scrounge some 400MHz gutless laptop to do builds on would massively improve my ability to work on the Mac OS X support. As it is, I just don't find it worth the effort, so it's mostly a couple of contributors who have Apple hardware doing the work.
I don't understand why Apple isn't handing out CDs of the early builds to developers in a way that'd make AOL look frugal. Surely they want to maximise exposure and get more developers trying it and using it now? There would be a lot of user installs too, but that'd only last as long as that version stayed current - by 10.6 or 10.7 those users might well be eyeing a Mac for an upgrade.
Personally, I'd *kill* for a Xen port of Mac OS X for developers, so I didn't even have to reboot from my normal productive working environment into Mac OS X... but I don't see it happening in a hurry.
Of course, such things are freely overlooked here when the publication in question isn't in favour. I don't like it personally, but evidently many are just fine with it.
There are lots of nice things in Apple's OpenFirmware, even though it's apparently crippled and butchered compared to the Sun ones. Those examples, however, are bad ones - you have all but the last in any PC BIOS worth its salt.
Even the last is probably possible, but too few PCs have FireWire built in for it to be interesting, and USB requires different hardware for host and "gadget" (client) mode.
Something I've seen missing from the discussion so far is much focus on understanding maps and navigation.
If you don't know how to read and use a map, it'll be much harder to make one that's even remotely useful. Get familiar with topographical maps, at bare minimum, and preferably other types you think might be appropriate. Study some cartography. Go out on a compass navigation training course - with not a single gadget on you.
I mean that about the training course, too. You'll learn much better that way, and learn things properly. Don't just think reading a book cuts it, you need to go out and get experience where you still have someone to pull you out or ask questions of.
Get the permission of the local authorities. Others have outlined why that's a very good idea.
I'd also suggest going on a few multi-day bushwalks before you leave. On at least one of them, preferably with someone experienced, leave your GPS unit at home. Why: (a) Bushwalking is fun, especially multi-day trips (b) it'll make you more confident in your ability to handle navigation and the work involved, and (c) you'll appreciate the practice.
Now, I've made some big assumptions about the sort of territory and environment you'll be working in. Even if you don't need the skills outlined above, though, they're darn good to have, darn fun to acquire, and it never hurts to be prepared.
While gcc isn't as good as any compiler written for just one arch, it's being improved fast. There's another factor people miss.
When I'm porting to a new arch, being able to use the same compiler is bliss. One less variable to worry about. I'll support gcc first, and only then consider compilers that only work on that arch.
"You can use your familiar tools" is a big attraction.
I have, in fact, responded that way to Excel. Not becuse I like Excel (I loathe spreadsheets with a passion that is difficut to convey) but because I'd just been using OpenOffice.org Calc and Excel was such an amazing relief that it was positively delightful.
Slashdot Mirror
Hmm... how many of those are features of the protocol, as opposed to features of one or more of the main server implementations?
I can easily understand why they might want to omit offline messages, for example. In addition to the matter of storage (which they're probably not that bothered about) there's the issue that they must then store and forward messages. That may be legally different to a direct "switching" rely or direct user<->user comms.
The gateways are probably a legal thing, and again probably a feature of specific server implementations.
As for file transfers and group chat, I don't get that. I can only imagine that to be client limitations - or do they not work even with 3rd party clients?
To load Windows, GRUB just chain-loads the bootloader on the primary Windows partition (what Windows will use as C: drive). That's actually 16 bit code, even on AMD64.
WinXP 64 bit ed may be different, but your post suggests you're using the basic XP.
If I recall correctly a definition like:
root (hd0,0)
chainload +1
should do the trick (adjusting root to match your win32 c: ). I use Fedora, so to be honest it "just works".
*HOWEVER* it sounds like you're trying to boot XP off a secondary disk. If XP thinks that disk is the primary disk (ie you installed XP then rearranged the disks), it'll get really confused when you load its boot sector, and will fail to boot. I don't know if it's an easy thing to fix - I've always just installed windows where I expect it to live (it installs quite happily on a secondary disk).
You might be able to boot the XP cd, run "fixboot" and "fixmbr" from the recovery console, then re-install GRUB from a Linux rescue CD.
Where exactly does socialism come into this? I happen to disagree with you on that (moderation being OK IMO) but anyway... I don't think it's relevant.
Australia is a regulated capitalist economy. Like most of them. Where monopolies cause problems - such as the case of Telstra - or in other cases of market failure, action is taken to address the problem.
In this case, that means forcing Telstra Wholesale to offer access to exchanges and lines at the same prices as it provides them to its retail devision.
Telstra used to be a government department. It was essentially *gifted* the national infrastructure. Don't start me on that. The least it can be expected to do is provide equitable access to that infrastructure.
I strongly suggest you study some economics before saying that free markets are the full solution to the problem. You're looking specifically for "externalities" and "market failure". Note that Telstra is one such instance where the natural free market fails to achieve the capitalist economic goal - efficient distribution of resources - *and* the social goal - equitable distribution of resources.
I also happen to disagree that the alternate delivery approaches you suggest are reasonable alternatives. It is in the interest of consumers to have DSL and dial-up available from a competitive market - that Telstra, left un-checked, would strangle or prevent from by denying access to exchanges and lines. (If you suggest just building another national infrastructure I'll have to laugh at you).
Cable in Australia is not the same as in the US. It is not already laid everywhere. Moreover, guess what - Telstra owns the main Cable network. BPL isn't available here. I'm not convinced it should be. WiFi ISPs are available in some areas, but I'm unconvinced it's a viable alternative to DSL. Ditto CDMA/GSM/3G and other radio technologies. DSL and dial-up are controlled by Telstra by virtue of their control of the infrastructure.
Think about it this way: Telstra is somewhat like "ma bell". Which the US government took action to break the monopoly of, I might add, by rather drastically splitting the company. (I wish we'd do that to Telstra - but into wholesale and retail arms, to eliminate the internal conflict of interest over wholesale access and service).
Anyway, speaking of economics, I have some more study to do.
Synchronous? I'm not sure fibre/ethernet is, actually - and more to the point, I suspect the fact that it's symmetric is more important.
I'm in Australia, and I must say - you folks are lucky by comparison to us, though it *is* getting better here. We have an agency called the ACCC - Australian Competition and Consumer Commission - that's been slowly beating the incumbent telco into shape.
This would be a valid issue - if there was any crime involved.
... "interesting" content and a date in 2048. The message made clear at the end that it was a fake, and there was nothing inappropriate in the message.
.vbs script that pops up a dialog saying "If this had been a malicious script, it could have destroyed all your work and broken your computer" has a profound effect, it seems.
Spoofing an email, or putting up a fake website, was not a crime last I heard.
Someone might try to take civil action against you if offended (trademark problems; leibel; etc) but the chances are pretty darn good they won't if you're doing it with their permission.
Personally, I think this is an important education tool. Where it becomes a problem is if it goes too far, into "oops! Look! this trojan has been on your system for a week emailing your credit card details to some dodgy site. I guess you should be more careful with your email."
I remember how I was finally able to wake a few people up about the issue of viruses and impersonation in the very early days of mass email worms - not long after the Melissa worm. Direct education attempts had failed with the staff, so I sent an email to all of them that pretended to be our Prime Minister (this is a newspaper) with some
It was remarkable how many people came to me and asked about that - it was clear that it'd managed to get their attention as simply explaining the issue ("the From: address doesn't guarantee that it's from who it says it is") had failed to do.
Despite almost computer illiterate users, we've been unaffected by email worms due to a combination of a paranoid mail gateway and such periodic reminders to users. Things like a
There are gzip accelerator PCI cards available for cases where CPU is an issue. Whether they're cheaper in large clusters than just adding some hosts or getting a bigger pipe, I don't know ... but they're another option.
I don't imagine it would be simple - network protocols rarely are.
That said, HTTP is pretty much made for it with its support for `Content-Encoding:', and the clear headers/body separation. You still have to do things like make sure the client understands gzip, of course.
The job would also be vastly simplified by zlib. I'd consider implementing your own gzip compressor pretty extreme when zlib is free and extremely well tested.
Er... what?
I'm not going to make the argument another fellow did (it can't corrupt your disk) 'cos it's not true, though you'd have to be pretty darn unlucky.
The more important point is - you were running Apache as root?! If so, I don't blame your boss. If not, how exactly did it corrupt the disk? I'd be putting my money on an unrelated error (without information to the contrary) personally - early disk failure, etc.
In general, though, firing someone for implementing software they've approved on a production server after testing is stupidity. That's not the sort of place I'd want to work anyway, frankly. He was middle management in a larger company I presume?
mod_gzip is a C program. Like any C program, some types of programming error can cause stack corruption, which can leave unexpected crud on the stack that is then executed by the CPU. It is not impossible that system calls will be part of said crap.
That said, it's not overly likely, and you'd have to be pretty unlucky to have something like that happen even when testing it and having it crash repeatedly.
The more important point is "What? You were running Apache as root?"
It's for exactly this reason that I never, ever "make install" as root. Everything is --prefix'ed to $HOME/apps/$APPNAME and installed as a normal user.
It doesn't help that I hack on build systems, so I have a decent idea just how nasty one could be if desired.
I'm pretty sure they've swapped in the UnixWare kernel, and ported over the useful OpenSewer bits.
UnixWare at least didn't require you to relink (not recompile) the kernel and reboot to change IP address.
I use OpenServer 5.0.5 at work. TCP/IP is an optional extra - it ships on the CDs, but you don't have to install it, and it's not available in the basic version of the OS.
What valid points McBride has give points straight to Sun, something I find immensely amusing.
Yep.
;-)
Most tellingly, I suspect NOBODY uses OpenServer for Internet-exposed hosts. It's used a lot for legacy systems inside the network, but as a public host is going to be pretty darn unusual.
It also has the advantage of having almost no features. sshd - nope. Apache? Only an ancient version from Skunkware, and I'm pretty sure that hasn't been patched.
It's rather harder to hack if it's relying on the protection of another host, and it exposes basically nothing but telnet anyway.
That said, McBride *does* make some good points, but they're the same ones made by Sun before - and Sun, unlike SCO, are the ones to go to if you don't want to use Linux. I'd love to see Sun take him up on his kernel challenge
If building in backdoors is so common, I'm shocked not have heard any major security advisories about compromised backdoors.
/single/ backdoor that'll work across a wide range of devices, and can't just be closed when access to it becomes public knowledge.
Even if they do, it's a heck of a lot better than a
... and in other news, I hate the extrans default on slashdot, and can't count brackets properly.
That code also assumes the reader knows that NULL is false (and hopefully that it's actually just a macro for `0', which is false).
While I see what you're getting at and generally agree with you, that's not always true.
( )));
... and probably lots more. There's no sane way to explain all that. You have to pick your balance of expecting people to use API documentation and know the language, while explaining to them the bits you think need more explanation. It's not easy, given that what needs explaining varies depending on the reader.
... probably hurts the brain of a programmer used to static languages like C++. It might be best to explain to a Python user, too, since it's not that commonly used. Similarly, if I was going to use recursive template metaprogramming in a C++ program I'd need to explain that in detail, because most C++ programers don't know about it - but I wouldn't expect to have to explain the cast operators.
You have to pick your "target audience." Do you assume they have a solid understanding of the language and tools (such as a framework/toolkit)? Do you assume they're an expert with them? With a large toolkit, or complex language (think C++ and MFC), especially with a lot of subtelties, it's *NOT* reasonable to assume the reader knows something just because you do.
In an open source C++ project, you might not even want to assume all that much knowledge of C++, to make it easier for people with a C background to follow what's going on and track down a bug.
The following, for example, is C++ that you might see in Qt code that calls out to Python's C API. It's also broken for non-latin-1 text coding, but this is just a sample:
<ecode>
Fred* fred1 = dynamic_cast<Fred*>(name);
Q_ASSERT(fred1);
PyObject* pystrName = PyString_FromString(fred1->fullName.latin1().data
if (!pystrName)
return NULL;
</ecode>
That relies on knowledge of:
- Pointers
- the dynamic_cast<> operator's behaviour, namely that it does a runtime check to see whether `name' can be cast to a Fred* based on inheritance (using RTTI), and returns 0 if it can not be cast.
- That Q_ASSERT is a macro that will check the pointer is not zero (depending on compile time flags, it'll print a warning or abort the program)
- that calls into the Python/C API return NULL when they've set an exception, and if you're going to be returning to Python you should return NULL to propagate the exception. (Otherwise you must PyErr_Print() or PyErr_Clear() it).
After all, this:
<ecode>
class Fred(object): pass
fredInstance = Fred()
def printName(self):
print "I'm Fred!"
Fred.printName = printName
fredInstance.printName()
</ecode>
I also think it's ok if someone looks puzzled by part of your code that's *genuinely* *hard*. Complex algorithms can take a while to understand, for example. There, your *goal* is to make them look like they're thinking hard, rather than have them exclaim "WTF!" or "huh? what the heck is this?".
Well, part of the reason, anyway. The Linux development process and developers are also indifferent to "out-of-tree" development, and fairly hostile to binary-only drivers. There is no stable API, let alone ABI, and no interest in maintaining one. Additionally, the kernel team are unwilling to accept "OS adaptor" compatibility layers in drivers.
That's not necessarily bad - it brings with it a lot of advantages - but it does mean that supporting Linux is a *LOT* of work for a hardware vendor. The user base must be correspondingly larger for it to be worth their while.
I find this an absolutely critical tool when designing and writing new classes. I don't usually write each method that way, but the overall class structure, the methods, and the members are all written as stubs and commented before any "real" code goes in.
I can't seem to "think it out on paper" but I *can* think it out in words in a header file, and massage that into the shape I want before starting any "real" code.
You make a good point about drivers. It's one I'm pretty sure I've made in response to others before, but it entirely slipped my mind today. We need only look at Darwin/x86 to see what a dismal base they'd be starting from on the driver front.
I'm not really convinced re the rest of your argument. Explicitly beta OS releases (with things like a boot-up message saying "This is a beta-quality demo. The full version of the OS will not run on your PC." might still be useful.
It's all well and good to tell folks to buy the Apple dev kit, until you look at the price tag. It's nothing for a developer who considers the Mac an important platform, but it'll prevent anybody who wants to check it out and see what possibilities there are from trying it out. In fairness, unless a developer has used a cross-platform toolkit like Qt they won't learn much without spending a lot more than that (in time, if nothing else) anyway.
Given the driver issue, I imagine a general release would be out. I still maintain that a XenU version would be very interesting, since only geeks and developers would want to run it anyway, given the most likely limited graphics support and the need for a Linux host OS, but it'd help get them more exposure among linux/UNIX developers.
Why should they? I work on an app that's cross platform - Linux, alpha on Mac OS X and a Win32 port in the works. Having access to the latest Mac OS X for free on my normal desktop without having to scrounge some 400MHz gutless laptop to do builds on would massively improve my ability to work on the Mac OS X support. As it is, I just don't find it worth the effort, so it's mostly a couple of contributors who have Apple hardware doing the work.
I don't understand why Apple isn't handing out CDs of the early builds to developers in a way that'd make AOL look frugal. Surely they want to maximise exposure and get more developers trying it and using it now? There would be a lot of user installs too, but that'd only last as long as that version stayed current - by 10.6 or 10.7 those users might well be eyeing a Mac for an upgrade.
Personally, I'd *kill* for a Xen port of Mac OS X for developers, so I didn't even have to reboot from my normal productive working environment into Mac OS X
Yep.
Of course, such things are freely overlooked here when the publication in question isn't in favour. I don't like it personally, but evidently many are just fine with it.
Too bad I don't have any mod points right now.
There are lots of nice things in Apple's OpenFirmware, even though it's apparently crippled and butchered compared to the Sun ones. Those examples, however, are bad ones - you have all but the last in any PC BIOS worth its salt.
Even the last is probably possible, but too few PCs have FireWire built in for it to be interesting, and USB requires different hardware for host and "gadget" (client) mode.
Don't throw them out. Donate them to any of the number of PC refurbishment and training charities that you'll find. They can always use good gear.
Something I've seen missing from the discussion so far is much focus on understanding maps and navigation.
If you don't know how to read and use a map, it'll be much harder to make one that's even remotely useful. Get familiar with topographical maps, at bare minimum, and preferably other types you think might be appropriate. Study some cartography. Go out on a compass navigation training course - with not a single gadget on you.
I mean that about the training course, too. You'll learn much better that way, and learn things properly. Don't just think reading a book cuts it, you need to go out and get experience where you still have someone to pull you out or ask questions of.
Get the permission of the local authorities. Others have outlined why that's a very good idea.
I'd also suggest going on a few multi-day bushwalks before you leave. On at least one of them, preferably with someone experienced, leave your GPS unit at home. Why: (a) Bushwalking is fun, especially multi-day trips (b) it'll make you more confident in your ability to handle navigation and the work involved, and (c) you'll appreciate the practice.
Now, I've made some big assumptions about the sort of territory and environment you'll be working in. Even if you don't need the skills outlined above, though, they're darn good to have, darn fun to acquire, and it never hurts to be prepared.
Yep.
While gcc isn't as good as any compiler written for just one arch, it's being improved fast. There's another factor people miss.
When I'm porting to a new arch, being able to use the same compiler is bliss. One less variable to worry about. I'll support gcc first, and only then consider compilers that only work on that arch.
"You can use your familiar tools" is a big attraction.
I have, in fact, responded that way to Excel. Not becuse I like Excel (I loathe spreadsheets with a passion that is difficut to convey) but because I'd just been using OpenOffice.org Calc and Excel was such an amazing relief that it was positively delightful.
Scary, eh?