Well, I am using a laptop with a 2.4GHz Core 2 Duo, 4GB of RAM, and a nice fast disk bundled into a little 13" machine. So you're close.
That said, there doesn't seem to be any significant performance hit - it's proportionately faster than my last laptop, a 2GHz Core Duo with 2GB of RAM. I don't experience any sluggishness or performance issues, and in some areas it performs a lot better than XP. The indexing service is well behaved and runs at a low priority, leaving plenty of disk I/O time for other apps, and it only does anything much when you've just been copying vast amounts of data around anyway. I consider it worth it, and if I didn't I'd just turn the indexer off.
Right now, Vista has only managed to use 1GB of my RAM at all. That includes RAM used by thunderbird, firefox, Adobe Reader, disk caches, and everything else. The disk caches are 750MB of that use, so the real RAM use is only 250MB. That, in my view, is not too bad. I'll accept some extra RAM hit in exchange for the other benefits of the OS, and since its' RAM use isn't far off what I see under Linux with similar workloads that's fine by me.
I'm not using this machine for games, though, and I do understand that there are real performance issues related to gaming under Vista. Hopefully most of those will smooth out with improved drivers etc, and the next generation of games being better tuned for the OS.
I do turn off the sidebar though. I don't see the need for it, and it's definitely a pig of a thing.
Yeah, the built-in DRM crap does give me the shudders. I don't have to use anything that relies on it, though, and I don't.
For similar reasons I buy very few games now, because I'm so sick of knowing that people who pirate the game get a better game than I do. It runs without a CD, it doesn't just randomly stop working sometimes, etc. I'd rather not have it at all most of the time. As such, I'm not hit very hard by compatibility issues with games. I also tend to view a little breakage as the price of progress, though I wish they'd made more progress, broken more, and introduced a better (though less transparent if necessary) compat layer / emulator / wrapper for older software.
I'm quite glad Vista makes it harder to install kernel drivers. I don't want random software installing kernel drivers, global hook DLLs, browser extensions, or any of that crap. It's best to avoid dodgy software completely, but this isn't always possible, and the harder MS make this sort of thing the happier I'll be - so long as legitimate uses remain possible.
The driver issue is a thorny one, since hardware manufacturers are not exactly enthusiastic about updating drivers - they see it as cannibalizing their own sales, and a waste of money. MS can't do the job, and can't really progress on their platform changes without making changes that make new drivers necessary. So new drivers aren't always available. That does suck, but really only tends to affect hardware that's either really cheap or quite old, so it's not the end of the world.
My only real complaint is that they're shoving Vista so hard down the throats of users. I understand why, but I don't have to like it.
I started out as a pre-judged Vista hater. When I got my new laptop (XPS 1330) I decided to give it a go anyway rather than just downgrading to XP. I'm glad - it's actually quite nice, and IMO a real step up from XP unless you have incompatible apps.
Vista's honestly not that bad. Quite nice in some areas. I've had no serious app compat issues - but then I only really use OSS apps, and those tend to be well behaved anyway since they're usually portable, and tend to be quickly updated for new platforms.
I find the UI a small but significant improvement, and I'm already in love with the indexing service's integration with the rest of the OS. Yes, mac users, I know about spotlight - I admin macs at work.
I'd also say that fears about battery life _on_ _new_ _hardware_ with the latest generation of mobile GPUs are somewhat overblown. I don't see a huge difference between Aero on and off - much as I see relatively little difference (1/2 an hour out of this laptops 4 1/2 at most) from activating Compiz on Ubuntu. I'm not even sure there's any effect at all, since whatever difference there is is well within the measurement inaccuracy of any battery testing.
It's not some huge leap forward - it's more like what Apple does between two Mac OS X releases (including the breakage of apps with rather hacky innards that people yell about - try admining a DTP lab with Adobe and Quark products and tell me how much you love Mac OS X updates). What it is, though, is a _lot_ of small and medium improvements rolled up into what I'd call an overall much better OS.
I'd feel pretty ripped off if I'd paid to upgrade from XP - but as a new OS it's quite nice. I don't find the UAC stuff annoying (though it was a HORROR in prereleases apparently) though I do think it's a waste of time that'll just get people clicking the dialogs without even thinking.
As it is, I find Vista much more usable than XP already. It took me a few hours to get used to some of the differences (and I still hate the control panel UI in "new mode" - though I'm sure it's OK for non-technical users) but it's now quite nice to use. I tend to switch between it and Ubuntu on my new laptop, depending on task.
The following PDF describes the specifics of the downgrade license process. It'll only do you any good if you have Vista Business or Vista Ultimate, unfortunately.
<p>I'm a little surprised MS haven't bent on Vista Home yet.</p>
<p>It's a pity, really. Vista could've been rather good, and does have some nice points. They did such a half-assed job on the security model - breaking things all over the place without really properly fixing it - that it seems like a missed opportunity though. I suspect an explicit "legacy mode" container a-la Mac Classic might've gone down better with customers in the end.</p>
One area where evolution just bites is on a machine with less than 1GB free RAM per user. It's an incredible RAM pig, especially for large IMAP mailboxes. As someone who hosts a thin client network, I'm not a fan. Thunderbird is a lot better. That said, I'm actually moving users over to kmail at the moment because (a) they prefer it and (b) it's more reliable - no random IMAP attachment download issues, no weird zombie processes hanging around after an unexpected X server death, and a more consistent and responsive UI.
Thunderbird is, however, without a doubt the best and possibly the only cross platform mail client that can do secure IMAP including client certificates. On some platforms the native client (I point particularly to Apple Mail) just don't work with IMAPs/IMAP+TLS and client certs at all. For that alone I hope it sticks around.
I'd be reluctant to go without IPv6 autoconfig. I run a DHCP server for IPv4 and enabling IPv6 wouldn't be too much hassle, but it's a great deal nicer not to have to. Arguments re shifting addresses are bogus, since you'll usually allocate addresses for services/network entities when you wish them to remain persistent anyway, just like you currently reserve static IPs in DHCP for servers.
I'm not too happy that no agreement has been reached on anycast DNS, though. The lack of a mechanism for clients to discover basic network services like DNS is a big hinderance.
Overall, though, I love the fact that I can plug my laptop in on any network and it'll either use native IPv6 (on enabled networks) or local 6to4 to get to any of my other v6 enabled hosts transparently. The old ssh proxy-command trick was bearable for punching through NAT, but v6 is so much nicer (and good for a great deal more than SSH of course).
Had the same level of scrutiny and criticism been applied to ODF than is being applied to OOXML there would be no ISO standard today
That's the key point in my mind, and what's been bothering me about much of this. It appears to me as a potential user of the spec (in my case transform of word processor docs) that as potential international standards they both stink. They're both tied to particular implementations and make decisions that simplify the use of the format with that implementation rather than seeking a representation that's clearer and easier to work with. It seems more like an OpenOffice-vs-MS-Office issue than an ODF vs OOXML one.
As a work documenting a format the OOXML spec is clearly massively superior. It's detailed, comprehensive, and nobody's screaming about inaccuracy yet either. The holes in the ODF spec are well known.
As a format I don't much like either of them. Then again, I'm not writing a spreadsheet or word processor - I'm only processing the data these apps produce for use in our in-house tools. As such I see much in the OOXML format I like, in particular that it makes room for preserving 3rd party XML in documents (a lack I find annoying in ODF and by extension OpenOffice). People argue that this lack is by design and intended to prevent "Embrace and Extend" - something I find nigh incomprehensible. To my mind the reverse is true, in that if a clean extension mechanism is provided there's no need to butcher the core format to do what you have to or make a whole new format to work around the inflexibility of the old one.
What bothers me is that as international standards neither seem satisfactory. Both are immature, insufficiently widely implemented, and based on a particular app's needs rather than trying to reach a generally useful format. ODF should not have been standardized, and standardizing OOXML to make up for that seems like a similarly awful idea.
On a side note, the fact that I've seen criticism of OOXML because it _doesn't_ store localized dates etc is just amazing. Do these people hand-translate their source code too, and write apps with XML element translation tables so that they can treat <file> and <datei> as the same thing? Does the German localized version of their app even read their English app's files? Picking one representation and sticking to it (be it US English in source code, or ISO dates in a file format) is the only sane way to do it, as you'll be well aware. The fact that people picked this argument up was the main thing that made me start questioning the anti-OOXML folks.
It still strikes me as a terrible idea to standardize it (it's a business ploy, much like the ISO standardization of ODF was more about marketing and politics than technology) but it looks like it might be an OK format to work with.
Then again, I'm a sysadmin & internal developer who maintains (not by choice) a large number of different platforms. I'm used to senseless zealotry from Linux people, Windows people and Mac people, all of whom make demonstrably false and often nonsensical claims about their favoured platforms and the ones they see as "opposed". This affair seems like much the same sort of thing.
I'm not convinced by that argument. PDF, for example, is highly extensible but has seen few problems in that regard. I'm not sure a technical approach to preventing the so called "embrace & extend" will be useful or effective - but it'll certainly make the format less useful for legitimate purposes.
What _will_ help is a good compliance test suite, and an understanding that it's *ok* to extend formats so long as you do so to include things that users need that the standard provides no way to represent and that are non-critical to the core functionality of the document. In general, if you can strip the extensions and still use the document, that's OK.
There are good reasons why you want to be able to extend document formats. Document management systems, for example, benefit considerably from being able to embed their own data in the XML document structure. Forms processing engines need this. In fact, most server-based document manipulation really wants to be able to keep it's own data in the document struture. I'm not convinced that ODF will be seriously adopted in government and large companies unless these things are possible. You might wonder why people use this stuff, and I can only offer my assurance that it can indeed be useful, since unless you've been working with lots of documents it's kind of hard to grasp. Even at my small company there are things like this that I'd like to be able to do to keep track of some of our work better.
MS will embrace & extend the format if they like, whether or not it makes explicit provision for extensibility. That's the problem. If the format is designed to be extensible, such efforts are less harmful, easier to make understood by other tools, and more susceptible to submission as subsidiary standards where they're generally useful. I think MS got this right to an extent with OOXML, and ODF will sooner or later have to follow a similar path or be replaced by something that can.
It's good that OOXML failed, as it's clearly just not suitable to be an international standard. I'm not sure ODF is either, though.
ODF is distinctly lacking in the `X' aspect of XML, for one thing. No provision is made for inserting your own data and having it preserved by apps that work on the format (one thing that MS _did_ get right in OOXML), for example. Large areas are unspecified. The comments that it's quite closely based on OO.o's internal workings are also far from inaccurate.
ODF might evolve into a good standard in a few revisions, but it's not one now IMO. I'm glad it passed because it'll make it harder to get even worse standards in place (but a truly technically excellent one should be able to supercede it) and because it has the potential to be improved into a quality standard. Right now, though, I can't imagine why anybody would go past PDF/A for archival, and can live with the somewhat clumsy limits on the current editable formats.
Naturally you'll want to look at one of the many Internet Kiosk setups out there.
My personal preference would be to roll out a thin client setup using Linux thin clients w firefox in kiosk mode as a full-screen login session. No viruses, if it crashes you reset it, etc. Simple - if you know some Linux. K12LTSP is helpful for those not already familiar with DHCP, tftp, etc and who lack an existing server infrastructure. Even if you do have an existing solid network I'd strongly recommend the LTSP base as a starting point - it's a great, non-invasive way to get the "client" part of the thin clients ready to go.
Another option would be to just use a generic system image. There are quite a few kiosk Linux distros that might do.
Why all this prattle about Linux? Because it's ideal for the job - basic functionality required, but it has to be tough, cheap, and easy to roll out. You could probably do it with WinXP Basic & Sysprep, but it'd cost you a bunch and you'd probably land up reimaging the machines regularly.
XP has a different scheduler, audio stack, and network stack. Unlike Vista it doesn't try all that hard to guarantee low latency audio (which pro audio folks care about a LOT). There is a throughput/latency tradeoff even across superficially unrelated subsystems on the same hardware, and that could easily explain these observed issues. There's plenty of technical literature out there on low-latency response techniques for providing soft-realtime features in otherwise non-realtime systems (like Vista is doing with audio) that will cover the issues with scheduling, interrupt handling, I/O contention, memory latencies, etc. It's not trivial.
I'm not sure it has to be as bad as it is in Vista (Linux manages vaguely OK in recent versions), nor it is necessarily required for the OS to go hard-out low-latency for basic music playback, but I don't think this issue is as incomprehensible as everyone's making out.
This issue is all about latency. It may not be that significant for basic music playback, but music player apps use the same subsystem as the pro DJ apps, sound editors, etc. Those care a lot about latency for a variety of reasons.
The network stack, by contrast, is focused on throughput. Latency is still significant, but not too much of an issue.
Balancing these requirements means that the host OS may have to make sacrifices in throughput to guarantee acceptably low latencies for audio.
I'm not convinced it _has_ to (Linux manages vaguely OK these days) or that basic audio players need full effort low-latency audio, but it's not as stupid as it seems on face value.
One poster has already pointed out one part of why your argument is oversimplified (cooperative multitasking).
In fact, Mac OS 7/8/9 are still hard to beat for soft realtime, because you can basically control the machine exclusively for as long as you want, giving access back to the OS only when it's convenient. If there are no other processes running (you've killed the Finder and aren't running anything but your app) it's impressive for audio etc.
There's another big reason, too. Your M601 based PowerMac didn't have gigabit ethernet. If it had, it couldn't have even processed the interrupts fast enough to count the packets it was dropping. (It didn't help that the 601 machines were NuBus based, but even had they been PCI it'd still be hopeless). I very much doubt a 601-based machine could even fully saturate 100baseTX. I know ours at work couldn't in network file I/O. On the other hand, with a 66MHz CPU that's hardly surprising.
I'm still very surprised that these effects are so significant. Soft realtime CPU scheduling guarantees to multimedia apps should not have to so dramatically affect machine throughput, though they'll probably have some effect. Look at Linux - it copes pretty well. Vista performing poorly in this area is unfortunate, but not so incomprehensible as many claim, especially since IIRC it does provide quite low latencies for audio apps.
The government isn't, as such, spending $84 million on a porn filter. They're spending $84 million subsidising licenses for 3rd party filter software at minimally discounted or non-discounted rates.
Frankly, I think it's nonsensical, but it DOES help keep the religious crazies quiet without them making another mandatory ISP filtering push. As if the last one (that was actually passed into law here!) ever had any effect beyond being openly ignored by ISPs as impractical and downright stupid. It stops them demanding something even more absurdly costly and embarrassing.
The resource fork wasn't that out there - some UNIX file systems had supported streams for ages. That said, as a desktop OS concept it was pretty damn weird.
I agree that it would've worked much better if it'd been implemented without relying on a file system level forked file concept. The same is true of the Mac file metadata (type/creator codes, etc), since both they and resource forks required quite a bit of annoyance to preserve across standard networks.
Not all cross platform issues would've been eliminated, though. Do you see Apple publishing a portable C/C++ "resource fork" library and/or full specs and keeping it up to date? Me neither.
People seem to think that because I find fault with Mac OS X, that implies that I find Linux to be perfect. That's absurd, and I've never suggested anything of the sort.
Linux zealots do indeed tend to suffer from many of the same reasoning and reality perception problems as Mac zealots.
Linux docs? Of course not. They vary from good to awful, like Mac OS X's.
As for fstab, your're quite right that it's gone from recent 10.4.x releases. Which is nice, though it'd be nicer if the poor confused sysadmin got the slightest hint where to go instead.
What bugs me is that people talk about Mac OS X like it's some grand uber-UNIX with none of the faults and all the benefits. In reality it's the same inconsistently documented, buggy, poorly maintained piece of crap that we're used to from every other UNIX-like OS. Of course, it throws in some fun new incompatibilities, UI pain (X11 on Mac OS X = bad), and challenges with dealing with the rest of the OS, and reminds you every 10 seconds that if you're not writing in Apple's preferred Objective C/Cocoa then you really don't matter as much. On the other hand, it has some distinctly nice aspects too, especially if you're not at all concerned with portability.
Mac OS X has a subsystem based on BSD, and it uses it for some system tasks and to present a POSIX runtime environment. It's only a very small part of the system and rather a second citizen. Let's not even talk about their X11 support, which is pretty unpleasant to use for anything but the basics.
Only a Mac zealot is likely to tell you it's just a "better unix than unix". Real unix users tend to cry when trying to use it, especially since half the man pages are outdated and completely wrong because Apple changed how everything works but didn't document it.
A better bet would be virtualization, given the realities of market share and the amount of time such a compatibility effort would take for relatively poor results. The Mac platform is also such a moving target that any such layer would be outdated by the time it was even close to working.
Unfortunately, Apple don't want to you run their precious OS in a virtual container. They want to force you to do everything else in a virtual container instead. They won't sell you a license to their OS for user in a virtual environment, and they won't permit you to run a license you own in a virtual environment even on their own hardware.* They are proving reasonably successful at using technical measures to enforce this. As such, you will have to run anything else you want to use under VMWare/Parallels, dual boot, or endure Apple's rather unpleasant X11 support.
* I find this highly amusing - in a "kill them all" kind of way - since they like to complain so much about MS's anti-virtualization terms. Kettle? Pot? . IMO all such terms are nothing short of stupid, irrespective of the vendor.
I'm not fond of the idea myself, as I suspect it'd never work well. Apple's OS is also a fast moving target and maintaining compatibility would be a nightmare.
I don't buy the "why not run Linux apps on Mac OS X" line though. Apple's X11 is a second citizen that is very poorly integrated into the UI, slow, and clumsy to use. They don't have to be, but Apple hasn't been too enthusiastic about improving X11 support. X11 apps are much easier to use on a native X11 desktop (obviously) and if they're most of what you need and use, moving to such a desktop might be a better option.
As a UNIX user, I'm also always really annoyed by Apple's outdated and incorrect documentation. Check out `man fstab' for example. I reported a bug about that being wrong and out of date (since it's function is now in netinfo, now OpenDirectory) more than two years ago. They just don't bother fixing the man pages when they rip some BSD-like behaviour out and replace it with Apple-specific features, so you never even know where to start looking. How do I automount an afp volume? Certainly not in fstab, but the documentation won't tell you that. Eventually you find out the netinfo format (totally different for afp than any other FS, with no documented reason why you have to use the url form) and use it. A while later, you figure out that the mount points are magic and you have to use/Network to get the machine to do the sane thing. ARGH!
So... I agree that there's little appeal to trying to kludge Apple apps on to Linux. I just don't think that makes using Mac OS X the logical choice - and I don't agree that it's a better unix than UNIX, as some like to claim. A new OS that uses a changed and somewhat mangled version of BSD for some of its functionality and provides a POSIX layer as one of its 5 major userspace realms, yes, but not a UNIX.
If I was in the situation of needing just a few Mac OS X apps, I'd probably want to use something like VMWare for that. Pity Apple won't let me buy a license to their OS separately to their hardware or run one that came with hardware I own under a virtual environment:S
As it is, I can only advise the poster to endure Apple's X11 implementation, or if that proves non-viable try using Linux in VMWare or Parallels.
The discussion of a replacement for the "file" abstraction seems a bit iffy. We've seen this before, many times, and it hasn't worked:
Files are a low level SHARED abstraction agreed upon by ALL major plaforms in use. Like the use of the C interface to communicate between components in an executable (no matter what language(s) they're written in) it's going to stay dominant unless you can convince everybody to change to your new one.
Because of (1), cross-platform data sharing will be much harder, and apps will have to support a conventional file format too. Especially for a niche platform that lacks the market power to force the new approach down everybody's throats.
It's very much like the Apple Resouce Fork - a quite nice (if imperfectly implemented and historically limited) approach to enhancing files. ResEdit was amazing. Unfortunately, the resource fork is fading from use because it was always a royal PITA for cross platform work, and because portable apps can't rely on it.
This is different to, say, Java's object serialization how?
In short: it seems they're improving object serialization. Nice, but hardly revolutionary, and likely to introduce fun problems when interoperating with software relying on it.
Re:Wel im not paying anything to extortion
on
Hotmail vs Goodmail
·
· Score: 1
AFAIK Sender ID support in a mail server is only required for verifying sender ID information on incoming mail. To enable sender ID on your domain so others can verify your mail, all you should need to do is add a TXT record to your domain that specifies a list of authorized servers.
Forwarding is somewhat of an issue, but the most common uses can be overcome by whitelisting the forwarding host. I personally don't think it's that big a deal, and in fact I have routinely whitelisted a couple of forwarding hosts for other reasons.
Slashdot Mirror
Yep. If I'd paid for it as an upgrade - especially the "ultimate" version - I'd feel right ripped off. The prices are absurd.
Well, I am using a laptop with a 2.4GHz Core 2 Duo, 4GB of RAM, and a nice fast disk bundled into a little 13" machine. So you're close.
That said, there doesn't seem to be any significant performance hit - it's proportionately faster than my last laptop, a 2GHz Core Duo with 2GB of RAM. I don't experience any sluggishness or performance issues, and in some areas it performs a lot better than XP. The indexing service is well behaved and runs at a low priority, leaving plenty of disk I/O time for other apps, and it only does anything much when you've just been copying vast amounts of data around anyway. I consider it worth it, and if I didn't I'd just turn the indexer off.
Right now, Vista has only managed to use 1GB of my RAM at all. That includes RAM used by thunderbird, firefox, Adobe Reader, disk caches, and everything else. The disk caches are 750MB of that use, so the real RAM use is only 250MB. That, in my view, is not too bad. I'll accept some extra RAM hit in exchange for the other benefits of the OS, and since its' RAM use isn't far off what I see under Linux with similar workloads that's fine by me.
I'm not using this machine for games, though, and I do understand that there are real performance issues related to gaming under Vista. Hopefully most of those will smooth out with improved drivers etc, and the next generation of games being better tuned for the OS.
I do turn off the sidebar though. I don't see the need for it, and it's definitely a pig of a thing.
Yeah, the built-in DRM crap does give me the shudders. I don't have to use anything that relies on it, though, and I don't.
For similar reasons I buy very few games now, because I'm so sick of knowing that people who pirate the game get a better game than I do. It runs without a CD, it doesn't just randomly stop working sometimes, etc. I'd rather not have it at all most of the time. As such, I'm not hit very hard by compatibility issues with games. I also tend to view a little breakage as the price of progress, though I wish they'd made more progress, broken more, and introduced a better (though less transparent if necessary) compat layer / emulator / wrapper for older software.
I'm quite glad Vista makes it harder to install kernel drivers. I don't want random software installing kernel drivers, global hook DLLs, browser extensions, or any of that crap. It's best to avoid dodgy software completely, but this isn't always possible, and the harder MS make this sort of thing the happier I'll be - so long as legitimate uses remain possible.
The driver issue is a thorny one, since hardware manufacturers are not exactly enthusiastic about updating drivers - they see it as cannibalizing their own sales, and a waste of money. MS can't do the job, and can't really progress on their platform changes without making changes that make new drivers necessary. So new drivers aren't always available. That does suck, but really only tends to affect hardware that's either really cheap or quite old, so it's not the end of the world.
My only real complaint is that they're shoving Vista so hard down the throats of users. I understand why, but I don't have to like it.
I started out as a pre-judged Vista hater. When I got my new laptop (XPS 1330) I decided to give it a go anyway rather than just downgrading to XP. I'm glad - it's actually quite nice, and IMO a real step up from XP unless you have incompatible apps.
Vista's honestly not that bad. Quite nice in some areas. I've had no serious app compat issues - but then I only really use OSS apps, and those tend to be well behaved anyway since they're usually portable, and tend to be quickly updated for new platforms.
I find the UI a small but significant improvement, and I'm already in love with the indexing service's integration with the rest of the OS. Yes, mac users, I know about spotlight - I admin macs at work.
I'd also say that fears about battery life _on_ _new_ _hardware_ with the latest generation of mobile GPUs are somewhat overblown. I don't see a huge difference between Aero on and off - much as I see relatively little difference (1/2 an hour out of this laptops 4 1/2 at most) from activating Compiz on Ubuntu. I'm not even sure there's any effect at all, since whatever difference there is is well within the measurement inaccuracy of any battery testing.
It's not some huge leap forward - it's more like what Apple does between two Mac OS X releases (including the breakage of apps with rather hacky innards that people yell about - try admining a DTP lab with Adobe and Quark products and tell me how much you love Mac OS X updates). What it is, though, is a _lot_ of small and medium improvements rolled up into what I'd call an overall much better OS.
I'd feel pretty ripped off if I'd paid to upgrade from XP - but as a new OS it's quite nice. I don't find the UAC stuff annoying (though it was a HORROR in prereleases apparently) though I do think it's a waste of time that'll just get people clicking the dialogs without even thinking.
As it is, I find Vista much more usable than XP already. It took me a few hours to get used to some of the differences (and I still hate the control panel UI in "new mode" - though I'm sure it's OK for non-technical users) but it's now quite nice to use. I tend to switch between it and Ubuntu on my new laptop, depending on task.
The following PDF describes the specifics of the downgrade license process. It'll only do you any good if you have Vista Business or Vista Ultimate, unfortunately.
<a>< ahref="http://download.microsoft.com/download/5/f/4/5f4c83d3-833e-4f11-8cbd-699b0c164182/royaltyoemreferencesheet.pdf">http://download.microsoft.com/download/5/f/4/5f4c83d3-833e-4f11-8cbd-699b0c164182/royaltyoemreferencesheet.pdf</a></p>
<p>I'm a little surprised MS haven't bent on Vista Home yet.</p>
<p>It's a pity, really. Vista could've been rather good, and does have some nice points. They did such a half-assed job on the security model - breaking things all over the place without really properly fixing it - that it seems like a missed opportunity though. I suspect an explicit "legacy mode" container a-la Mac Classic might've gone down better with customers in the end.</p>
One area where evolution just bites is on a machine with less than 1GB free RAM per user. It's an incredible RAM pig, especially for large IMAP mailboxes. As someone who hosts a thin client network, I'm not a fan. Thunderbird is a lot better. That said, I'm actually moving users over to kmail at the moment because (a) they prefer it and (b) it's more reliable - no random IMAP attachment download issues, no weird zombie processes hanging around after an unexpected X server death, and a more consistent and responsive UI.
Thunderbird is, however, without a doubt the best and possibly the only cross platform mail client that can do secure IMAP including client certificates. On some platforms the native client (I point particularly to Apple Mail) just don't work with IMAPs/IMAP+TLS and client certs at all. For that alone I hope it sticks around.
I'd be reluctant to go without IPv6 autoconfig. I run a DHCP server for IPv4 and enabling IPv6 wouldn't be too much hassle, but it's a great deal nicer not to have to. Arguments re shifting addresses are bogus, since you'll usually allocate addresses for services/network entities when you wish them to remain persistent anyway, just like you currently reserve static IPs in DHCP for servers.
I'm not too happy that no agreement has been reached on anycast DNS, though. The lack of a mechanism for clients to discover basic network services like DNS is a big hinderance.
Overall, though, I love the fact that I can plug my laptop in on any network and it'll either use native IPv6 (on enabled networks) or local 6to4 to get to any of my other v6 enabled hosts transparently. The old ssh proxy-command trick was bearable for punching through NAT, but v6 is so much nicer (and good for a great deal more than SSH of course).
That's the key point in my mind, and what's been bothering me about much of this. It appears to me as a potential user of the spec (in my case transform of word processor docs) that as potential international standards they both stink. They're both tied to particular implementations and make decisions that simplify the use of the format with that implementation rather than seeking a representation that's clearer and easier to work with. It seems more like an OpenOffice-vs-MS-Office issue than an ODF vs OOXML one.
As a work documenting a format the OOXML spec is clearly massively superior. It's detailed, comprehensive, and nobody's screaming about inaccuracy yet either. The holes in the ODF spec are well known.
As a format I don't much like either of them. Then again, I'm not writing a spreadsheet or word processor - I'm only processing the data these apps produce for use in our in-house tools. As such I see much in the OOXML format I like, in particular that it makes room for preserving 3rd party XML in documents (a lack I find annoying in ODF and by extension OpenOffice). People argue that this lack is by design and intended to prevent "Embrace and Extend" - something I find nigh incomprehensible. To my mind the reverse is true, in that if a clean extension mechanism is provided there's no need to butcher the core format to do what you have to or make a whole new format to work around the inflexibility of the old one.
What bothers me is that as international standards neither seem satisfactory. Both are immature, insufficiently widely implemented, and based on a particular app's needs rather than trying to reach a generally useful format. ODF should not have been standardized, and standardizing OOXML to make up for that seems like a similarly awful idea.
On a side note, the fact that I've seen criticism of OOXML because it _doesn't_ store localized dates etc is just amazing. Do these people hand-translate their source code too, and write apps with XML element translation tables so that they can treat <file> and <datei> as the same thing? Does the German localized version of their app even read their English app's files? Picking one representation and sticking to it (be it US English in source code, or ISO dates in a file format) is the only sane way to do it, as you'll be well aware. The fact that people picked this argument up was the main thing that made me start questioning the anti-OOXML folks.
It still strikes me as a terrible idea to standardize it (it's a business ploy, much like the ISO standardization of ODF was more about marketing and politics than technology) but it looks like it might be an OK format to work with.
Then again, I'm a sysadmin & internal developer who maintains (not by choice) a large number of different platforms. I'm used to senseless zealotry from Linux people, Windows people and Mac people, all of whom make demonstrably false and often nonsensical claims about their favoured platforms and the ones they see as "opposed". This affair seems like much the same sort of thing.
I'm not convinced by that argument. PDF, for example, is highly extensible but has seen few problems in that regard. I'm not sure a technical approach to preventing the so called "embrace & extend" will be useful or effective - but it'll certainly make the format less useful for legitimate purposes.
What _will_ help is a good compliance test suite, and an understanding that it's *ok* to extend formats so long as you do so to include things that users need that the standard provides no way to represent and that are non-critical to the core functionality of the document. In general, if you can strip the extensions and still use the document, that's OK.
There are good reasons why you want to be able to extend document formats. Document management systems, for example, benefit considerably from being able to embed their own data in the XML document structure. Forms processing engines need this. In fact, most server-based document manipulation really wants to be able to keep it's own data in the document struture. I'm not convinced that ODF will be seriously adopted in government and large companies unless these things are possible. You might wonder why people use this stuff, and I can only offer my assurance that it can indeed be useful, since unless you've been working with lots of documents it's kind of hard to grasp. Even at my small company there are things like this that I'd like to be able to do to keep track of some of our work better.
MS will embrace & extend the format if they like, whether or not it makes explicit provision for extensibility. That's the problem. If the format is designed to be extensible, such efforts are less harmful, easier to make understood by other tools, and more susceptible to submission as subsidiary standards where they're generally useful. I think MS got this right to an extent with OOXML, and ODF will sooner or later have to follow a similar path or be replaced by something that can.
It's good that OOXML failed, as it's clearly just not suitable to be an international standard. I'm not sure ODF is either, though.
ODF is distinctly lacking in the `X' aspect of XML, for one thing. No provision is made for inserting your own data and having it preserved by apps that work on the format (one thing that MS _did_ get right in OOXML), for example. Large areas are unspecified. The comments that it's quite closely based on OO.o's internal workings are also far from inaccurate.
ODF might evolve into a good standard in a few revisions, but it's not one now IMO. I'm glad it passed because it'll make it harder to get even worse standards in place (but a truly technically excellent one should be able to supercede it) and because it has the potential to be improved into a quality standard. Right now, though, I can't imagine why anybody would go past PDF/A for archival, and can live with the somewhat clumsy limits on the current editable formats.
Sorry, instead of "WinXP Basic" I meant "WinXP Starter Edition" - and it doesn't appear to be available in most countries anyway.
Naturally you'll want to look at one of the many Internet Kiosk setups out there.
My personal preference would be to roll out a thin client setup using Linux thin clients w firefox in kiosk mode as a full-screen login session. No viruses, if it crashes you reset it, etc. Simple - if you know some Linux. K12LTSP is helpful for those not already familiar with DHCP, tftp, etc and who lack an existing server infrastructure. Even if you do have an existing solid network I'd strongly recommend the LTSP base as a starting point - it's a great, non-invasive way to get the "client" part of the thin clients ready to go.
Another option would be to just use a generic system image. There are quite a few kiosk Linux distros that might do.
Why all this prattle about Linux? Because it's ideal for the job - basic functionality required, but it has to be tough, cheap, and easy to roll out. You could probably do it with WinXP Basic & Sysprep, but it'd cost you a bunch and you'd probably land up reimaging the machines regularly.
XP has a different scheduler, audio stack, and network stack. Unlike Vista it doesn't try all that hard to guarantee low latency audio (which pro audio folks care about a LOT). There is a throughput/latency tradeoff even across superficially unrelated subsystems on the same hardware, and that could easily explain these observed issues. There's plenty of technical literature out there on low-latency response techniques for providing soft-realtime features in otherwise non-realtime systems (like Vista is doing with audio) that will cover the issues with scheduling, interrupt handling, I/O contention, memory latencies, etc. It's not trivial.
I'm not sure it has to be as bad as it is in Vista (Linux manages vaguely OK in recent versions), nor it is necessarily required for the OS to go hard-out low-latency for basic music playback, but I don't think this issue is as incomprehensible as everyone's making out.
This issue is all about latency. It may not be that significant for basic music playback, but music player apps use the same subsystem as the pro DJ apps, sound editors, etc. Those care a lot about latency for a variety of reasons.
The network stack, by contrast, is focused on throughput. Latency is still significant, but not too much of an issue.
Balancing these requirements means that the host OS may have to make sacrifices in throughput to guarantee acceptably low latencies for audio.
I'm not convinced it _has_ to (Linux manages vaguely OK these days) or that basic audio players need full effort low-latency audio, but it's not as stupid as it seems on face value.
One poster has already pointed out one part of why your argument is oversimplified (cooperative multitasking).
In fact, Mac OS 7/8/9 are still hard to beat for soft realtime, because you can basically control the machine exclusively for as long as you want, giving access back to the OS only when it's convenient. If there are no other processes running (you've killed the Finder and aren't running anything but your app) it's impressive for audio etc.
There's another big reason, too. Your M601 based PowerMac didn't have gigabit ethernet. If it had, it couldn't have even processed the interrupts fast enough to count the packets it was dropping. (It didn't help that the 601 machines were NuBus based, but even had they been PCI it'd still be hopeless). I very much doubt a 601-based machine could even fully saturate 100baseTX. I know ours at work couldn't in network file I/O. On the other hand, with a 66MHz CPU that's hardly surprising.
I'm still very surprised that these effects are so significant. Soft realtime CPU scheduling guarantees to multimedia apps should not have to so dramatically affect machine throughput, though they'll probably have some effect. Look at Linux - it copes pretty well. Vista performing poorly in this area is unfortunate, but not so incomprehensible as many claim, especially since IIRC it does provide quite low latencies for audio apps.
--
Craig Ringer
The government isn't, as such, spending $84 million on a porn filter. They're spending $84 million subsidising licenses for 3rd party filter software at minimally discounted or non-discounted rates.
Frankly, I think it's nonsensical, but it DOES help keep the religious crazies quiet without them making another mandatory ISP filtering push. As if the last one (that was actually passed into law here!) ever had any effect beyond being openly ignored by ISPs as impractical and downright stupid. It stops them demanding something even more absurdly costly and embarrassing.
It was my pet peeve as well. They've "fixed" it for 10.4 by deleting /etc/fstab and still not fixing the man page.
The resource fork wasn't that out there - some UNIX file systems had supported streams for ages. That said, as a desktop OS concept it was pretty damn weird.
I agree that it would've worked much better if it'd been implemented without relying on a file system level forked file concept. The same is true of the Mac file metadata (type/creator codes, etc), since both they and resource forks required quite a bit of annoyance to preserve across standard networks.
Not all cross platform issues would've been eliminated, though. Do you see Apple publishing a portable C/C++ "resource fork" library and/or full specs and keeping it up to date? Me neither.
People seem to think that because I find fault with Mac OS X, that implies that I find Linux to be perfect. That's absurd, and I've never suggested anything of the sort.
Linux zealots do indeed tend to suffer from many of the same reasoning and reality perception problems as Mac zealots.
Linux docs? Of course not. They vary from good to awful, like Mac OS X's.
As for fstab, your're quite right that it's gone from recent 10.4.x releases. Which is nice, though it'd be nicer if the poor confused sysadmin got the slightest hint where to go instead.
What bugs me is that people talk about Mac OS X like it's some grand uber-UNIX with none of the faults and all the benefits. In reality it's the same inconsistently documented, buggy, poorly maintained piece of crap that we're used to from every other UNIX-like OS. Of course, it throws in some fun new incompatibilities, UI pain (X11 on Mac OS X = bad), and challenges with dealing with the rest of the OS, and reminds you every 10 seconds that if you're not writing in Apple's preferred Objective C/Cocoa then you really don't matter as much. On the other hand, it has some distinctly nice aspects too, especially if you're not at all concerned with portability.
Anyway, you're an AC so why am I bothering.
Mac OS X has a subsystem based on BSD, and it uses it for some system tasks and to present a POSIX runtime environment. It's only a very small part of the system and rather a second citizen. Let's not even talk about their X11 support, which is pretty unpleasant to use for anything but the basics.
Only a Mac zealot is likely to tell you it's just a "better unix than unix". Real unix users tend to cry when trying to use it, especially since half the man pages are outdated and completely wrong because Apple changed how everything works but didn't document it.
A better bet would be virtualization, given the realities of market share and the amount of time such a compatibility effort would take for relatively poor results. The Mac platform is also such a moving target that any such layer would be outdated by the time it was even close to working.
Unfortunately, Apple don't want to you run their precious OS in a virtual container. They want to force you to do everything else in a virtual container instead. They won't sell you a license to their OS for user in a virtual environment, and they won't permit you to run a license you own in a virtual environment even on their own hardware.* They are proving reasonably successful at using technical measures to enforce this. As such, you will have to run anything else you want to use under VMWare/Parallels, dual boot, or endure Apple's rather unpleasant X11 support.
* I find this highly amusing - in a "kill them all" kind of way - since they like to complain so much about MS's anti-virtualization terms. Kettle? Pot? . IMO all such terms are nothing short of stupid, irrespective of the vendor.
I'm not fond of the idea myself, as I suspect it'd never work well. Apple's OS is also a fast moving target and maintaining compatibility would be a nightmare.
/Network to get the machine to do the sane thing. ARGH!
... I agree that there's little appeal to trying to kludge Apple apps on to Linux. I just don't think that makes using Mac OS X the logical choice - and I don't agree that it's a better unix than UNIX, as some like to claim. A new OS that uses a changed and somewhat mangled version of BSD for some of its functionality and provides a POSIX layer as one of its 5 major userspace realms, yes, but not a UNIX.
:S
I don't buy the "why not run Linux apps on Mac OS X" line though. Apple's X11 is a second citizen that is very poorly integrated into the UI, slow, and clumsy to use. They don't have to be, but Apple hasn't been too enthusiastic about improving X11 support. X11 apps are much easier to use on a native X11 desktop (obviously) and if they're most of what you need and use, moving to such a desktop might be a better option.
As a UNIX user, I'm also always really annoyed by Apple's outdated and incorrect documentation. Check out `man fstab' for example. I reported a bug about that being wrong and out of date (since it's function is now in netinfo, now OpenDirectory) more than two years ago. They just don't bother fixing the man pages when they rip some BSD-like behaviour out and replace it with Apple-specific features, so you never even know where to start looking. How do I automount an afp volume? Certainly not in fstab, but the documentation won't tell you that. Eventually you find out the netinfo format (totally different for afp than any other FS, with no documented reason why you have to use the url form) and use it. A while later, you figure out that the mount points are magic and you have to use
So
If I was in the situation of needing just a few Mac OS X apps, I'd probably want to use something like VMWare for that. Pity Apple won't let me buy a license to their OS separately to their hardware or run one that came with hardware I own under a virtual environment
As it is, I can only advise the poster to endure Apple's X11 implementation, or if that proves non-viable try using Linux in VMWare or Parallels.
The discussion of a replacement for the "file" abstraction seems a bit iffy. We've seen this before, many times, and it hasn't worked:
In short: it seems they're improving object serialization. Nice, but hardly revolutionary, and likely to introduce fun problems when interoperating with software relying on it.
AFAIK Sender ID support in a mail server is only required for verifying sender ID information on incoming mail. To enable sender ID on your domain so others can verify your mail, all you should need to do is add a TXT record to your domain that specifies a list of authorized servers.
Forwarding is somewhat of an issue, but the most common uses can be overcome by whitelisting the forwarding host. I personally don't think it's that big a deal, and in fact I have routinely whitelisted a couple of forwarding hosts for other reasons.