That sounds fairly darn civilized to me. In particular, I'm much less bothered by a keyserver approach when I know the game won't just stop working if the company that makes it encounters difficulties. Keyserver based approaches seem relatively inoffensive, and I imageine they'd stop a lot of casual copying. I can understand why they have a bad rep (it could be done very badly, ie game not playable/installable if the key server is unreachable so you no longer even really "own" the game; privacy issues) but honestly if I'm stuck with copy protection I'll take a keyserver system over CD-based systems any day.
I'm glad to hear about the lack of any requirement for a CD in the drive. I'm pleasantly surprised to find that you have a local reseller that I already have dealings with. Given that this game sounds like just my thing (almost as much as the X-com games, Star Control 2, Master of Orion II, System Shock II or Deus Ex), I'll certainly have to put my money where my mouth is. I may also have to grab Postal simply to have it on the shelf;-)
I'd still be interested to know your views on the effectiveness of traditional CD-based copy protection, given the comments I made earlier.
By the way, congrats on being brave enough to take on this market. I'd be pretty wary myself, what with binary compatibility issues across distros and versions, a significant proportion of spending-allergic or foaming zealot users who equate free with gratis, etc. I find it quite challenging enough maintaining software that is recompiled for each distro/version. *shudder*autotools*shudder.
Actually, this article is about one of the points you raised. The display has fairly high pixel dimensions, but since it's a very large display it's not actually that high resolution. It's nothing fancy in that regard - no pores on skin here.
What it *does* do, according to the spec, is solve the greyish blacks and muddy whites problem. Comprehensively. That's what a contrast ratio means - it's the ratio in brightness between the brightest white and darkest black the display can produce/at the same time/.
I read that list, thinking "Surely nobody could use something that dodgy?". Well, boy was I wrong - I own one of them, Splinter Cell Chaos Theory.
No wonder the bloody thing never worked quite right. I was struck by the even-more-appalling-than-usual copy protection when I installed it. It was done sufficiently incompetently that it had *two* keys - one for install, and one for LAN play. The copy protection verification takes 30s on startup. It's astonishingly broken, and I won't be buying anything else from Ubi unless I can confirm they've fixed the issue.
Now I know why. Thanks for bringing this up, as now I have a good list of even more offensive than usual copy protected games to avoid like the plague. Now, where's that removal tool....
That's unfortunate, though I can understand where you're coming from, of course.
I'd be interested to know if copy protection actually visibly improved sales, though. In my experience it's totally ineffective (I generally won't buy a game until I've played it and confirmed it doesn't suck / isn't hopelessly buggy, so I know this first-hand), and it also significantly discourages me from buying a game. In particular, I'm vastly more willing to pay good money for anything that won't force me to find the blasted disk every time I want to play it. I'm *much* more willing to buy games with non-offsensive or no copy protection.
The pile of boxes beside me shows that rather clearly (well, except half life 2 - I'm not a zealot, and while I don't like Steam at least it doens't require the bloody DVD in the drive!).
What confuses me most, though, is that copy protection doesn't appear to actually work. Not for big name games, anyway. It's trivial to find either copies of the game that are illegally distributed with the copy protection removed, or programs that will remove copy protection from an installed copy. It's been like that for more than 15 years. (As I said, I generally play a game a bit before I buy it. Remove that option, and I just stop buying games I haven't been able to try at a friend's). Do you find that it actually makes a difference to your sales? I've always suspected it was pushed on developers by a publisher who "doesn't get it" or a 3rd party copy protection product's sales guy doing some fast talking to upper management. I'd be fascinated to know, since I often suspect that in the case of big name games all it achieves is annoyance for legit customers.
I've "fixed" several of the games I've bought simply because finding the CD/DVD to play it got so annoying. The most offensive thing is that people who illegally copied the game don't have to do this - it's actually *better* for them.
The only effective copy protection I've seen is the requirement for a valid key for online play using the company's servers. What's more, that's not disruptive for the player and pretty much inoffensive. I can't wrap my head around why these games, in particular, still use CD copy protection.
I bought Neverwinter Nights partly because of its Linux support - one less game I have to reboot to play - and especially because that support was entirely free of copy protection. Similarly I was very happy with Quake 3. I only bought Quake 3 a *long* time after it came out, when I was finally in a position to actually buy games. I hunted it down specifically because it's a well built game with nice linux support and 100% inoffensive copy protection. I bought BF 1942's expansions in no small part because, while copy protected, they let you play with multiple people on a LAN at somewhat saner prices. AU$300 per person is kind of stupid for a game, and that's what it would've cost if each player had to have the game and all ex packs.
A linux-supported game with minimal or no copy protection is much more likely to get my money, and I'll pay more for it too. I'm much less likely to wait 'till it hits the bargain bin, and will generally be a bunch happier with it simply because it makes playing it fun, not infuriating and frustrating. Ditto anything that doesn't force me to sit through 5 mins of unskippable logos etc just to play the thing, doesn't require the disk in the drive, etc.
Actually, Brian didn't make any comment on import. That was what I'd written there, well before the arrival of Slashdot, and I thought it pretty useless to repeat here. It's nothing to do with anyone at Microsoft's views as far as I know.
this comment on another thread here is what I wrote to clarify a few things to someone else.
I expect the products you've referenced will be best-effort importers. I don't see how you could do a full-fidelity round trip through Word, after all. That's cool, and best-effort can be pretty darn good, but it's entirely possible that Microsoft doesn't want to do that. I explained one possible reason above. Another would be that they don't want to disturb the complacency of people who think PDF is read only;-) . They might also simply not think there's any demand, or not enough to make it worth implementing / buying.
Well, I'm impressed. I'll have to have a play with that, even if it involves installing KDE;-)
Honestly,/within certain limits/ importing PDF isn't/that/ bad. It's very tricky, but do-able. The key limitation is not expecting a round-trip to leave the file unmangled. Another crucial one is to accept that your import will not work on all PDFs, only those that fit certain criteria. There's a big difference between import of supported text and graphics content in a best-effort at layout, and trying to support full-fidelity editing that preserves all unmodified content.
What's the bet that if MS tried a basic importer, people would start screaming about "embracing and extending," especially if they used the perfectly legal and utterly harmless (viewers can just ignore them) option of embedding custom XML snippets in PDF to improve the fidelity of the import of Office-generated PDF ?
In this case, I don't think so. There are readily available compliance tools available, PDF is controlled by Adobe (who may get pretty grumpy if MS play fast and loose with the standard), and anyway it looks like MS may have its own format in the running soon.
If they try to "embrace and extend" with PDF in Office, they're likely to get the same result they did with HTML export from Word - lots of laughter.
Honestly, to me this looks like them just trying to add a feature their users have been loudly demanding for five years.
I'm with you there. I always disable the Adobe PDF plugin. It'd be nice to have a browser-based viewer that didn't suck so totally, completely, and utterly as Adobe's, as I suspect a lot of people's dislike of PDF comes from that apalling piece of garbage as much as anything else.
Note that nobody has said anything about Microsoft offering a PDF viewer implementation at all. It would seem logical, but I'm not convinced it's all that likely If they do, I'd expect a super-basic one like Apple's first-generation Preview, or a bundled cut-down Adobe Reader.
This is very odd. I've seen almost no comments along the lines of "Yay, native PDF support in this software that lots of people use, now maybe they'll stop emailing me bloody word docs."
Rather, there's lots of ranting about innovation, and lots of people saying that $[software] did it first. Yep, sure. I have an unpleasant revelation for you - *none* of the software industry is exactly a powerhouse of innovation. They all implement ideas that came from each other, improve them or butcher them along the way, and try to compete. OO.o may have had PDF export first, but it's UI is a bad clone of an even worse UI (Office '97). Office might be picking up PDF export pretty late in the game, but on the other hand it looks like they're working to fix the train wreck that is office suite user interfaces. Similarly, Apple and Microsoft are busy chasing each other, nicking each other's ideas, and coming up with the odd good one along the way. Arguing about who is most innovative is just not interesting. Ideas come from all the involved parties, and everybody steals them. Big deal.
To me, this just looks like MS doing something sensible, often requested by customers, and perhaps long overdue. It's beyond me why all the comments here are so overwhelmingly negative.
Slashdot isn't usually this bad, folks. What's gotten into this bunch today?
For those talking about printer-driver based PDF export, it's not that simple. Here's what I posted earlier. Summary: OS based would be nice, but a simple generic print interface would be insufficiently flexible so something more would be needed anyway. Anyway, if they built PDF export into the OS, I bet this crowd would be screaming about monopolies, bundling, and anticompetitive business practices.
I find all this pretty disappointing. There are posts on the forum thread with the new user interface screenshots that are foaming crazy, and they all prominently say "I support open source!" or rant about OSS. Yet so many folks here wonder why nobody is interested in listening when someone has something constructive and rational to say. I begin to wonder if the crazies are the loud majority, rather than the loud minority...
The majority, if not all, of the issues you describe are with the viewer, not the format. Moreover, many are solved by learning to use the viewer. Continuous view, with an appropriate page fit setting, will solve the majority of the problems you've described.
Personally, while I don't have poor vision, I do like large and highly readable text since I work on computers a *lot*, and I have a very high resolution display as well. I rarely find PDF to be a problem in this regard. I'm generally as happy with PDF as with HTML or any other format, and much happier with it than with some.
I work in newspaper publishing, and I can assure you that PDF is for *much* more than a paper replacement. It's quite simply the only sane format to use when you want to aggregate several smaller jobs into a larger one - such as when designing a page with client-supplied advertisments in it. PDF lets the recipient provide a basic specification (all fonts embedded, PDF 1.3, 10cm by 12cm, CMYK colour) and rely on that - without having to worry about different apps, incompatible versions, fonts, different platforms, or all sorts of other garbage.
It's also great for archiving anything where you need to preserve the appearance, not just the content. It's not a bad idea to archive the content as well, since extracting content from PDF can be painful (it's a page description language, not a traditional document format), but it's darn handy.
Oooooh yeah. You didn't get the full OpenServer rant;-)
It may be stable, and well documented, but that's about where the good bits end. Yes, the scoadmin tools are buggy as hell. On the other hand, they exist, and frankly that's better than any Linux I've ever used. I also dislike, however, the fact that the scoadmin tools hide what they really do from you - there's precious little information about what files a tool will affect, etc.
OpenServer's `lpd' is pure evil - I smell sulphur whenever I have to work with it. It's hard to configure, quirky, unreliable, archaic, and the admin tools for it are way more broken than for any other part of the scoadmin suite. It's currently making 800 DNS requests per second to my local DNS server. The conversation goes something like this:
SCO: what's my hostname? My IP is 10.0.0.8 . DNS: alder.localnet. SCO: what's my hostname? My IP is 10.0.0.8 . DNS: alder.localnet, just like the last bajillion times. SCO: What's my hostname? My IP is 10.0.0.8 . DNS: *shoots self in head*
Additionally, the lpd service tends to silently quit, or to start two copies of its self then stop working. That particular bug has been confirmed by all other SCO admins I've met, too. Alas, their compiler suite seems archaic and it's a nightmare to get it to work, so I haven't been able to build lprng or god forbid CUPS as a replacement print service.
So yeah... not a big fan. The fact is, however, that the core OS is still extremely stable. I find OpenServer decent enough, print services aside, so long as I never need to actually *change* anything. I'll take Linux any day, but it's definitely not up there in the stability or "just put it in and forget about it" admin requirements stakes.
First - "legacy" apps are important. Perhaps they're not that big a deal for a home desktop, but in many other uses they're crucial. From that accounting app you use over remote X from your 1995 Sun server to the custom X11-based RAD that your business's customer tracking was done in, these things are important. There's no need to make them more painful to use than you have to. Unlike Apple, who have a strong incentive to push people over to Cocoa and Carbon (their APIs, their apps), I don't see why a new UNIX GUI system would have to penalize users for using older software. Why not make the transition painless for users, and less painful for developers?
Of course, there would have to be a limit. There are still people in the Windows world using win16 code in new versions of currently shipping applications, and that's just shocking.
When it comes to integration, yes, the clipboard could be tricky to do *really* well, because the X11 and Apple clipboards work very differently. Really, though, text is most important - and for that, though, they need only use an X11 clipboard proxy app like most people use as an add-on for Xdarwin and Cygwin. They could probably even handle image copy+paste if they wanted, by saving to a temp file and giving the X11 app a URI to the temp file.
As for printing, I think you're dead wrong. Apple already uses CUPS, and could do a lot with that. It's already much better than it could be thanks to CUPS. If they wanted to provide the Apple print dialog to X apps, the approach used by KPrinter would work well there.
My complaint is, above all else, the dock. I see no good reason why X11 windows should not show up in the dock, other than that Apple felt like ensuring that X11 apps would always be clunky second-citizens in Mac OS X. It also appears to be harder than it should be to give your windows their own menu bar as Mac users expect, instead of the X server menu bar (even though the Carbon API is available to X11 apps, much of it is cripped because Mac GUI apps need to be launched a special way, and Xdarwin doesn't do it).
I was lucky, in that the app I mostly work on uses Qt, so we were able to migrate from Qt/X11 to Qt/Mac and have it take care of much of the pain. Others are not so lucky, and can't achieve minimal integration with the OS environment without first undertaking a massive port to Carbon/Aqua.
Microsoft does appear to have addressed many of the win16 compat legacy stuff with Windows.Net Forms, and it sounds like more is to go with Avalon. Still, XUL, as as workaround for the Win32 UI API, is essentially a toolkit that talks directly to the lower levels of the system, instead of using the system's dominant GUI toolkit. I like Qt for similar reasons. Hence my view that toolkits are an important and useful part of GUI interfaces, if done right, and might be a better approach overall than a "one true platform API". Among other things, toolkits can be cross platform.
I do agree that toolkits on X11 are too low level, with not enough communication and commonality between them. Some of this is now improving, but there's a *long* way to go. FreeDesktop.org seems to be helping, but only slowly. It'd be nice to see platforms providing services for GUI toolkits, rather than trying to impose their own "one right answer", and I have the feeling that'd help with toolkit interoperation. Don't even get me started on file and print dialogs, though...
Perhaps so. If the replacement is decent, and can host a fully backward compatible X server, I'd probably be happy. Frankly, though, I'd hope it'd learn the lessions of X11 - good *and* bad. You're quite right that there are serious problems with X11 its self. I tend to forget, especially when confronted by foaming ranting about it by people who clearly have even less idea than me what they're on about, such as some of the replies to your post.
I'd be very, very, very glad to see Xauth, X resources, X core fonts, etc dead forever. Eeew. Ditto Xlib, and the monolithic X server. That said, I think the "penalty box" idea is a stupid one. There's no good reason not to make X11 apps integrate cleanly into any new window system, and doing otherwise is most likely going to be punishing users because the system's developers don't like the apps they want to use. I'm looking at you, Apple.
Any new system would be very stupid not to handle network transparent operation - and do it better than X, especially with roaming clients. Similarly, I think it's clear that an exensible protocol is useful and important, and that X11 got the "mechanism not policy" approach right. They just forgot that some policy is still a very important - you just shouldn't build it into the protocol. I also think there's almost certainly still going to be a place for toolkits. I hope so, since toolkits are what free UNIX GUI developers from much of the legacy horror faced by win32 coders, and let app developers choose a framework that's best suited to their application. It'd be nice if the toolkits interoperated on a much higher level, though. Similarly, it'd be completely insane not to make the client libraries independent of the server as much as possible, since this has worked extremely well for X11 throughout its history. It's just unfortunate that the client libs in question are horrific.
"Most problems with Linux on the desktop are problems with X."
I couldn't disagree more. There are usability issues, documentation problems, missing features, etc. None of this is caused by X. I have seen _zero_ evidence that X11 is in any way a problem. The protocol is great, and I think we'd be nuts to ditch such a powerful, network transparent facility. As a developer, I'm not fond of the Xlib APIs, but there's work to replace Xlib now. The XFree86/XOrg implementation of the server could be better built so that it was in many small parts - but that's only a problem for people doing lots of low-level distro hacking, and for distributors. Again, there's progress to modularize it anyway.
X11 is not slow. Some X11 drivers are slow, but that's a driver issue and changing the window system will still leave you with crap drivers. For that, you need people who really understand the guts of the hardware, and you need good documentation. I should note that my system is *extremely* snappy under X11. In general, I find decent ATi and NVidia cards get very good results. If you're talking about 3D, that's in my view quite separate - but again, comes down to driver support and no documentation from vendors.
Nothing in X11 makes apps that use X11 ugly. Seriously. It's *WAY* too low level. Your complaint is most likely with the toolkits, themes, etc. If not, I'd be interested to know what in X11 you think causes the problem.
I'll certainly give you the points on X11 configuration and maintainance. I personally find it pretty painless, but then I have good hardware. I also find X11 to be very stable, though there have been times in the past I've sworn rather loudly about it (usually due to bad drivers or hardware).
The VT system could work a lot better, and I'm looking forward with enthusiasm to the move of much of the frame-buffer programming back to the kernel where it belongs. That should help solve a number of irritations.
I suspect you may have hit the reliability nail on the head if you're talking about rebuilding Xorg/XFree86, fontconfig, etc. If not done very carefully and with a good knowledge of the system, you'll quite possibly break things here. In particular, you need to be 100% sure that your new versions are ABI-compatible, unless you isolate them and only use apps you built against them with them. Your comment suggests that you do not, since Fontconfig has nothing to do with font rendering, and if there's anything you should be rebuilding (but you don't actually generally need to) it's freetype.
Of course, I find I get extremely good quality fonts anyway, so I can't say I've ever felt the need. Fonts under Linux used to be horrific - eye searing examples of pure horror. This has, in my view, been entirely resolved by recent freetype libraries and the ditching of X core fonts in favour of client-side rendering.
I personally find X11 one of the most attractive things about Linux. There are some issues with the implementation, but the power and flexibility of the protocol is not something I'd want to give up. I do agree that it could use some more work, but I'm unwilling to whine about it when I lack the time, skills, and motivation to do it myself. I personally think the current X work is important, and it looks like it'll lead toward more radical enhancements once the more basic issues with the codebase are addressed.
I find the same. I have an old NT4 box that runs wonderfully.
It used to be hideously unreliable. I migrated some services off it - in particular, the awful MDaemon mail server and MailScanner - and ever since, it's run rather well.
My experience has generally followed this - the Windows OS runs well, if the apps are good. If the apps are bad, the whole OS will run unreliably.
My Linux servers are pretty reliable too. Honestly, I think they all suck compared to the SCO OpenServer box I run on the reliability front, but I suspect that's because OpenServer does things the safe way even when it's the dumb and very, very slow way.
Perhaps. Really, though, the answer is "somewhere inbetween". That's why I said "consider using...";-) . DB app GUIs make it too easy to overlook, or too hard to use, the facilities the database will have to help you, and this generally limits your design choices. In many cases, that's just fine, but in others it can be a serious issue. It's understandable - the smaller, simpler subset of features these apps limit themselves to using in the database host, the fewer quirks they have to deal with and the fewer things they need to emulate for storage engines that don't support them. I'm just not convinced it results in well-designed databases.
I also argue that the app developer's job extends well into the database, in that for many apps views and stored procedures are as much a part of their application as the "real" code. At the app/DB interface like the interface between their various app modules, they should be considering clean design and separation there too, rather than poking directly into some other module's structures. After all, the DBA needs to be a part of the app development if possible, and they're really maintaining a module just like everybody else.
In this context, "developer" is the user who is building a specific database implementation on top of a GUI database app like Access, rather than the developer who wrote that application.
Hmm... all we need now is a "do it all in the application" nut and a "do it all in the database" nut and we can get a proper three-way flamefest going. Hmm. I'm waiting, and there's still no smell of sulphur - is it possible that being moderate and standing in the middle ground won't get me flamed to death? We'll see.
PHPMyAdmin and MySQL Control Center are database management GUIs. I don't think they're supposed to be Access-like apps, and I'm personally happy about that, since when doing DB admin I don't want a tool that tries to second guess me, hides things from me, etc.
One Access-like app is OpenOffice.org 2.0 Base (Go test it and report issues before the final OpenOffice.org 2.0 release!). It's extremely new and it's rough around the edges, but it looks decent. It's an Access clone to the point where I'm surprised Microsoft aren't suing about stolen icons.
If you're looking for something in the same vein, but not seeking a direct Access rip-off, then Rekall may be an option worth investigating. Both it an OO.o are cross-platform.
Do be aware that tools like Access encourage you to do too much client-side. It's important to consider using in-database stored procedures and (often updateable) views where appropriate for efficiency and clean structure. You can then use an Access-like app to provide a user-interface to that higher level database interface, instead of just poking around in the raw tables.
That's reasonable for some very high level subsystems in the kernel. For most things, such as drivers, the scheduler, etc, it's probably not.
Sometimes defining "pass" and "fail" is hard enough, with tuning efforts. Then there's cleanups. On top of that there are fixes to obsure drivers for hardware that nobody on LKML actually has.
I'm all for unit test based development, but there are some levels where it's practical, and some where I don't think it is. An OS kernel is to an extent the impractical side. I do like the idea of unit-tests from userspace to make sure nothing userspace-visible breaks, though.
You're joking... but it's not entirely a joke. The fact is that as a user who wants flexibility and customisation from my UI, in many ways I find KDE more friendly than the Mac OS X Finder. I find that Mac OS X's UI significantly hinders my ability to work quickly and effectively.
Yes, that's just a personal thing. Yes, most users are the opposite. Still... my point is that "user friendly" to one person can be user hostile to another.
The site does appear cleaner visually as well, which is nice. The comments post page in particular is much neater and nicer. I'm absolutely overjoyed to find little or no use of "px" for fonts in the style sheets - and thus, I can finally read slashdot without having to force the font size up first. That'll make users with poor vision, and those with extremely high res monitors, very happy.
So... kudos to the slashcode team. I know how hard cleanups (and presumably lots of refactoring behind the scenese) like this are.
FTP and client-side encryption is a bit of an icky hack though. It also doesn't protect your FTP session from attack (password theft, use of the FTP server for storing things you don't know about, etc).
I'd be waaay happier with WebDAV and client certs. It's a similar concept, in terms of being remote file storage, but is much more secure and lacks the headache-inducing pain of FTP. No firewall problems either, since it's plain 'ol HTTPs as far as the firewall / proxy is concerned.
I went poking around the site trying to find out what it supports in terms of roaming. Being able to just pull down a.jar from anywhere, and have a writeable LDAP+TLS address book, IMAP+TLS mail (both protected by SSL clent certs), etc all preconfigured would just be bliss.
Right now, it's hard enough to find a client that supports writeable LDAP address books at all, let alone usably and with TLS and client cert support.
Alas, their website doesn't seem to have any sort of feature summary, so it's rather hard to say w/o grabbing and trying it out.
Yes, it's a difficult situation where your control is limited and those running the other parts of the system aren't concerned about the issues or willing to listen.
As for the network, if you do get the chance then a good stackable managed switch (ie backplane stacking , not connect-the-uplinks) with serial console is your best friend:-)
Slashdot Mirror
That sounds fairly darn civilized to me. In particular, I'm much less bothered by a keyserver approach when I know the game won't just stop working if the company that makes it encounters difficulties. Keyserver based approaches seem relatively inoffensive, and I imageine they'd stop a lot of casual copying. I can understand why they have a bad rep (it could be done very badly, ie game not playable/installable if the key server is unreachable so you no longer even really "own" the game; privacy issues) but honestly if I'm stuck with copy protection I'll take a keyserver system over CD-based systems any day.
;-)
I'm glad to hear about the lack of any requirement for a CD in the drive. I'm pleasantly surprised to find that you have a local reseller that I already have dealings with. Given that this game sounds like just my thing (almost as much as the X-com games, Star Control 2, Master of Orion II, System Shock II or Deus Ex), I'll certainly have to put my money where my mouth is. I may also have to grab Postal simply to have it on the shelf
I'd still be interested to know your views on the effectiveness of traditional CD-based copy protection, given the comments I made earlier.
By the way, congrats on being brave enough to take on this market. I'd be pretty wary myself, what with binary compatibility issues across distros and versions, a significant proportion of spending-allergic or foaming zealot users who equate free with gratis, etc. I find it quite challenging enough maintaining software that is recompiled for each distro/version. *shudder*autotools*shudder.
Actually, this article is about one of the points you raised. The display has fairly high pixel dimensions, but since it's a very large display it's not actually that high resolution. It's nothing fancy in that regard - no pores on skin here.
/at the same time/.
What it *does* do, according to the spec, is solve the greyish blacks and muddy whites problem. Comprehensively. That's what a contrast ratio means - it's the ratio in brightness between the brightest white and darkest black the display can produce
I read that list, thinking "Surely nobody could use something that dodgy?". Well, boy was I wrong - I own one of them, Splinter Cell Chaos Theory.
No wonder the bloody thing never worked quite right. I was struck by the even-more-appalling-than-usual copy protection when I installed it. It was done sufficiently incompetently that it had *two* keys - one for install, and one for LAN play. The copy protection verification takes 30s on startup. It's astonishingly broken, and I won't be buying anything else from Ubi unless I can confirm they've fixed the issue.
Now I know why. Thanks for bringing this up, as now I have a good list of even more offensive than usual copy protected games to avoid like the plague. Now, where's that removal tool....
That's unfortunate, though I can understand where you're coming from, of course.
... what are your thoughts?
I'd be interested to know if copy protection actually visibly improved sales, though. In my experience it's totally ineffective (I generally won't buy a game until I've played it and confirmed it doesn't suck / isn't hopelessly buggy, so I know this first-hand), and it also significantly discourages me from buying a game. In particular, I'm vastly more willing to pay good money for anything that won't force me to find the blasted disk every time I want to play it. I'm *much* more willing to buy games with non-offsensive or no copy protection.
The pile of boxes beside me shows that rather clearly (well, except half life 2 - I'm not a zealot, and while I don't like Steam at least it doens't require the bloody DVD in the drive!).
What confuses me most, though, is that copy protection doesn't appear to actually work. Not for big name games, anyway. It's trivial to find either copies of the game that are illegally distributed with the copy protection removed, or programs that will remove copy protection from an installed copy. It's been like that for more than 15 years. (As I said, I generally play a game a bit before I buy it. Remove that option, and I just stop buying games I haven't been able to try at a friend's). Do you find that it actually makes a difference to your sales? I've always suspected it was pushed on developers by a publisher who "doesn't get it" or a 3rd party copy protection product's sales guy doing some fast talking to upper management. I'd be fascinated to know, since I often suspect that in the case of big name games all it achieves is annoyance for legit customers.
I've "fixed" several of the games I've bought simply because finding the CD/DVD to play it got so annoying. The most offensive thing is that people who illegally copied the game don't have to do this - it's actually *better* for them.
The only effective copy protection I've seen is the requirement for a valid key for online play using the company's servers. What's more, that's not disruptive for the player and pretty much inoffensive. I can't wrap my head around why these games, in particular, still use CD copy protection.
I bought Neverwinter Nights partly because of its Linux support - one less game I have to reboot to play - and especially because that support was entirely free of copy protection. Similarly I was very happy with Quake 3.
I only bought Quake 3 a *long* time after it came out, when I was finally in a position to actually buy games. I hunted it down specifically because it's a well built game with nice linux support and 100% inoffensive copy protection. I bought BF 1942's expansions in no small part because, while copy protected, they let you play with multiple people on a LAN at somewhat saner prices. AU$300 per person is kind of stupid for a game, and that's what it would've cost if each player had to have the game and all ex packs.
A linux-supported game with minimal or no copy protection is much more likely to get my money, and I'll pay more for it too. I'm much less likely to wait 'till it hits the bargain bin, and will generally be a bunch happier with it simply because it makes playing it fun, not infuriating and frustrating. Ditto anything that doesn't force me to sit through 5 mins of unskippable logos etc just to play the thing, doesn't require the disk in the drive, etc.
So
Actually, Brian didn't make any comment on import. That was what I'd written there, well before the arrival of Slashdot, and I thought it pretty useless to repeat here. It's nothing to do with anyone at Microsoft's views as far as I know.
;-) . They might also simply not think there's any demand, or not enough to make it worth implementing / buying.
this comment on another thread here is what I wrote to clarify a few things to someone else.
I expect the products you've referenced will be best-effort importers. I don't see how you could do a full-fidelity round trip through Word, after all. That's cool, and best-effort can be pretty darn good, but it's entirely possible that Microsoft doesn't want to do that. I explained one possible reason above. Another would be that they don't want to disturb the complacency of people who think PDF is read only
Well, I'm impressed. I'll have to have a play with that, even if it involves installing KDE ;-)
/within certain limits/ importing PDF isn't /that/ bad. It's very tricky, but do-able. The key limitation is not expecting a round-trip to leave the file unmangled. Another crucial one is to accept that your import will not work on all PDFs, only those that fit certain criteria. There's a big difference between import of supported text and graphics content in a best-effort at layout, and trying to support full-fidelity editing that preserves all unmodified content.
Honestly,
What's the bet that if MS tried a basic importer, people would start screaming about "embracing and extending," especially if they used the perfectly legal and utterly harmless (viewers can just ignore them) option of embedding custom XML snippets in PDF to improve the fidelity of the import of Office-generated PDF ?
In this case, I don't think so. There are readily available compliance tools available, PDF is controlled by Adobe (who may get pretty grumpy if MS play fast and loose with the standard), and anyway it looks like MS may have its own format in the running soon.
If they try to "embrace and extend" with PDF in Office, they're likely to get the same result they did with HTML export from Word - lots of laughter.
Honestly, to me this looks like them just trying to add a feature their users have been loudly demanding for five years.
I'm with you there. I always disable the Adobe PDF plugin. It'd be nice to have a browser-based viewer that didn't suck so totally, completely, and utterly as Adobe's, as I suspect a lot of people's dislike of PDF comes from that apalling piece of garbage as much as anything else.
Note that nobody has said anything about Microsoft offering a PDF viewer implementation at all. It would seem logical, but I'm not convinced it's all that likely If they do, I'd expect a super-basic one like Apple's first-generation Preview, or a bundled cut-down Adobe Reader.
This is very odd. I've seen almost no comments along the lines of "Yay, native PDF support in this software that lots of people use, now maybe they'll stop emailing me bloody word docs."
Rather, there's lots of ranting about innovation, and lots of people saying that $[software] did it first. Yep, sure. I have an unpleasant revelation for you - *none* of the software industry is exactly a powerhouse of innovation. They all implement ideas that came from each other, improve them or butcher them along the way, and try to compete. OO.o may have had PDF export first, but it's UI is a bad clone of an even worse UI (Office '97). Office might be picking up PDF export pretty late in the game, but on the other hand it looks like they're working to fix the train wreck that is office suite user interfaces. Similarly, Apple and Microsoft are busy chasing each other, nicking each other's ideas, and coming up with the odd good one along the way. Arguing about who is most innovative is just not interesting. Ideas come from all the involved parties, and everybody steals them. Big deal.
To me, this just looks like MS doing something sensible, often requested by customers, and perhaps long overdue. It's beyond me why all the comments here are so overwhelmingly negative.
Slashdot isn't usually this bad, folks. What's gotten into this bunch today?
For those talking about printer-driver based PDF export, it's not that simple. Here's what I posted earlier. Summary: OS based would be nice, but a simple generic print interface would be insufficiently flexible so something more would be needed anyway. Anyway, if they built PDF export into the OS, I bet this crowd would be screaming about monopolies, bundling, and anticompetitive business practices.
I find all this pretty disappointing. There are posts on the forum thread with the new user interface screenshots that are foaming crazy, and they all prominently say "I support open source!" or rant about OSS. Yet so many folks here wonder why nobody is interested in listening when someone has something constructive and rational to say. I begin to wonder if the crazies are the loud majority, rather than the loud minority...
Unlikely. PDF import is WAY harder than export. here's an explanation I prepared earlier..
It's not that simple.
The majority, if not all, of the issues you describe are with the viewer, not the format. Moreover, many are solved by learning to use the viewer. Continuous view, with an appropriate page fit setting, will solve the majority of the problems you've described.
Personally, while I don't have poor vision, I do like large and highly readable text since I work on computers a *lot*, and I have a very high resolution display as well. I rarely find PDF to be a problem in this regard. I'm generally as happy with PDF as with HTML or any other format, and much happier with it than with some.
I work in newspaper publishing, and I can assure you that PDF is for *much* more than a paper replacement. It's quite simply the only sane format to use when you want to aggregate several smaller jobs into a larger one - such as when designing a page with client-supplied advertisments in it. PDF lets the recipient provide a basic specification (all fonts embedded, PDF 1.3, 10cm by 12cm, CMYK colour) and rely on that - without having to worry about different apps, incompatible versions, fonts, different platforms, or all sorts of other garbage.
It's also great for archiving anything where you need to preserve the appearance, not just the content. It's not a bad idea to archive the content as well, since extracting content from PDF can be painful (it's a page description language, not a traditional document format), but it's darn handy.
Oooooh yeah. You didn't get the full OpenServer rant ;-)
... not a big fan. The fact is, however, that the core OS is still extremely stable. I find OpenServer decent enough, print services aside, so long as I never need to actually *change* anything. I'll take Linux any day, but it's definitely not up there in the stability or "just put it in and forget about it" admin requirements stakes.
It may be stable, and well documented, but that's about where the good bits end. Yes, the scoadmin tools are buggy as hell. On the other hand, they exist, and frankly that's better than any Linux I've ever used. I also dislike, however, the fact that the scoadmin tools hide what they really do from you - there's precious little information about what files a tool will affect, etc.
OpenServer's `lpd' is pure evil - I smell sulphur whenever I have to work with it. It's hard to configure, quirky, unreliable, archaic, and the admin tools for it are way more broken than for any other part of the scoadmin suite. It's currently making 800 DNS requests per second to my local DNS server. The conversation goes something like this:
SCO: what's my hostname? My IP is 10.0.0.8 .
DNS: alder.localnet.
SCO: what's my hostname? My IP is 10.0.0.8 .
DNS: alder.localnet, just like the last bajillion times.
SCO: What's my hostname? My IP is 10.0.0.8 .
DNS: *shoots self in head*
Additionally, the lpd service tends to silently quit, or to start two copies of its self then stop working. That particular bug has been confirmed by all other SCO admins I've met, too. Alas, their compiler suite seems archaic and it's a nightmare to get it to work, so I haven't been able to build lprng or god forbid CUPS as a replacement print service.
So yeah
First - "legacy" apps are important. Perhaps they're not that big a deal for a home desktop, but in many other uses they're crucial. From that accounting app you use over remote X from your 1995 Sun server to the custom X11-based RAD that your business's customer tracking was done in, these things are important. There's no need to make them more painful to use than you have to. Unlike Apple, who have a strong incentive to push people over to Cocoa and Carbon (their APIs, their apps), I don't see why a new UNIX GUI system would have to penalize users for using older software. Why not make the transition painless for users, and less painful for developers?
.Net Forms, and it sounds like more is to go with Avalon. Still, XUL, as as workaround for the Win32 UI API, is essentially a toolkit that talks directly to the lower levels of the system, instead of using the system's dominant GUI toolkit. I like Qt for similar reasons. Hence my view that toolkits are an important and useful part of GUI interfaces, if done right, and might be a better approach overall than a "one true platform API". Among other things, toolkits can be cross platform.
Of course, there would have to be a limit. There are still people in the Windows world using win16 code in new versions of currently shipping applications, and that's just shocking.
When it comes to integration, yes, the clipboard could be tricky to do *really* well, because the X11 and Apple clipboards work very differently. Really, though, text is most important - and for that, though, they need only use an X11 clipboard proxy app like most people use as an add-on for Xdarwin and Cygwin. They could probably even handle image copy+paste if they wanted, by saving to a temp file and giving the X11 app a URI to the temp file.
As for printing, I think you're dead wrong. Apple already uses CUPS, and could do a lot with that. It's already much better than it could be thanks to CUPS. If they wanted to provide the Apple print dialog to X apps, the approach used by KPrinter would work well there.
My complaint is, above all else, the dock. I see no good reason why X11 windows should not show up in the dock, other than that Apple felt like ensuring that X11 apps would always be clunky second-citizens in Mac OS X. It also appears to be harder than it should be to give your windows their own menu bar as Mac users expect, instead of the X server menu bar (even though the Carbon API is available to X11 apps, much of it is cripped because Mac GUI apps need to be launched a special way, and Xdarwin doesn't do it).
I was lucky, in that the app I mostly work on uses Qt, so we were able to migrate from Qt/X11 to Qt/Mac and have it take care of much of the pain. Others are not so lucky, and can't achieve minimal integration with the OS environment without first undertaking a massive port to Carbon/Aqua.
Microsoft does appear to have addressed many of the win16 compat legacy stuff with Windows
I do agree that toolkits on X11 are too low level, with not enough communication and commonality between them. Some of this is now improving, but there's a *long* way to go. FreeDesktop.org seems to be helping, but only slowly. It'd be nice to see platforms providing services for GUI toolkits, rather than trying to impose their own "one right answer", and I have the feeling that'd help with toolkit interoperation. Don't even get me started on file and print dialogs, though...
Perhaps so. If the replacement is decent, and can host a fully backward compatible X server, I'd probably be happy. Frankly, though, I'd hope it'd learn the lessions of X11 - good *and* bad. You're quite right that there are serious problems with X11 its self. I tend to forget, especially when confronted by foaming ranting about it by people who clearly have even less idea than me what they're on about, such as some of the replies to your post.
I'd be very, very, very glad to see Xauth, X resources, X core fonts, etc dead forever. Eeew. Ditto Xlib, and the monolithic X server. That said, I think the "penalty box" idea is a stupid one. There's no good reason not to make X11 apps integrate cleanly into any new window system, and doing otherwise is most likely going to be punishing users because the system's developers don't like the apps they want to use. I'm looking at you, Apple.
Any new system would be very stupid not to handle network transparent operation - and do it better than X, especially with roaming clients. Similarly, I think it's clear that an exensible protocol is useful and important, and that X11 got the "mechanism not policy" approach right. They just forgot that some policy is still a very important - you just shouldn't build it into the protocol. I also think there's almost certainly still going to be a place for toolkits. I hope so, since toolkits are what free UNIX GUI developers from much of the legacy horror faced by win32 coders, and let app developers choose a framework that's best suited to their application. It'd be nice if the toolkits interoperated on a much higher level, though. Similarly, it'd be completely insane not to make the client libraries independent of the server as much as possible, since this has worked extremely well for X11 throughout its history. It's just unfortunate that the client libs in question are horrific.
"Most problems with Linux on the desktop are problems with X."
I couldn't disagree more. There are usability issues, documentation problems, missing features, etc. None of this is caused by X. I have seen _zero_ evidence that X11 is in any way a problem. The protocol is great, and I think we'd be nuts to ditch such a powerful, network transparent facility. As a developer, I'm not fond of the Xlib APIs, but there's work to replace Xlib now. The XFree86/XOrg implementation of the server could be better built so that it was in many small parts - but that's only a problem for people doing lots of low-level distro hacking, and for distributors. Again, there's progress to modularize it anyway.
X11 is not slow. Some X11 drivers are slow, but that's a driver issue and changing the window system will still leave you with crap drivers. For that, you need people who really understand the guts of the hardware, and you need good documentation. I should note that my system is *extremely* snappy under X11. In general, I find decent ATi and NVidia cards get very good results. If you're talking about 3D, that's in my view quite separate - but again, comes down to driver support and no documentation from vendors.
Nothing in X11 makes apps that use X11 ugly. Seriously. It's *WAY* too low level. Your complaint is most likely with the toolkits, themes, etc. If not, I'd be interested to know what in X11 you think causes the problem.
I'll certainly give you the points on X11 configuration and maintainance. I personally find it pretty painless, but then I have good hardware. I also find X11 to be very stable, though there have been times in the past I've sworn rather loudly about it (usually due to bad drivers or hardware).
The VT system could work a lot better, and I'm looking forward with enthusiasm to the move of much of the frame-buffer programming back to the kernel where it belongs. That should help solve a number of irritations.
I suspect you may have hit the reliability nail on the head if you're talking about rebuilding Xorg/XFree86, fontconfig, etc. If not done very carefully and with a good knowledge of the system, you'll quite possibly break things here. In particular, you need to be 100% sure that your new versions are ABI-compatible, unless you isolate them and only use apps you built against them with them. Your comment suggests that you do not, since Fontconfig has nothing to do with font rendering, and if there's anything you should be rebuilding (but you don't actually generally need to) it's freetype.
Of course, I find I get extremely good quality fonts anyway, so I can't say I've ever felt the need. Fonts under Linux used to be horrific - eye searing examples of pure horror. This has, in my view, been entirely resolved by recent freetype libraries and the ditching of X core fonts in favour of client-side rendering.
I personally find X11 one of the most attractive things about Linux. There are some issues with the implementation, but the power and flexibility of the protocol is not something I'd want to give up. I do agree that it could use some more work, but I'm unwilling to whine about it when I lack the time, skills, and motivation to do it myself. I personally think the current X work is important, and it looks like it'll lead toward more radical enhancements once the more basic issues with the codebase are addressed.
I find the same. I have an old NT4 box that runs wonderfully.
It used to be hideously unreliable. I migrated some services off it - in particular, the awful MDaemon mail server and MailScanner - and ever since, it's run rather well.
My experience has generally followed this - the Windows OS runs well, if the apps are good. If the apps are bad, the whole OS will run unreliably.
My Linux servers are pretty reliable too. Honestly, I think they all suck compared to the SCO OpenServer box I run on the reliability front, but I suspect that's because OpenServer does things the safe way even when it's the dumb and very, very slow way.
Perhaps. Really, though, the answer is "somewhere inbetween". That's why I said "consider using ..." ;-) . DB app GUIs make it too easy to overlook, or too hard to use, the facilities the database will have to help you, and this generally limits your design choices. In many cases, that's just fine, but in others it can be a serious issue. It's understandable - the smaller, simpler subset of features these apps limit themselves to using in the database host, the fewer quirks they have to deal with and the fewer things they need to emulate for storage engines that don't support them. I'm just not convinced it results in well-designed databases.
... all we need now is a "do it all in the application" nut and a "do it all in the database" nut and we can get a proper three-way flamefest going. Hmm. I'm waiting, and there's still no smell of sulphur - is it possible that being moderate and standing in the middle ground won't get me flamed to death? We'll see.
I also argue that the app developer's job extends well into the database, in that for many apps views and stored procedures are as much a part of their application as the "real" code. At the app/DB interface like the interface between their various app modules, they should be considering clean design and separation there too, rather than poking directly into some other module's structures. After all, the DBA needs to be a part of the app development if possible, and they're really maintaining a module just like everybody else.
In this context, "developer" is the user who is building a specific database implementation on top of a GUI database app like Access, rather than the developer who wrote that application.
Hmm
PHPMyAdmin and MySQL Control Center are database management GUIs. I don't think they're supposed to be Access-like apps, and I'm personally happy about that, since when doing DB admin I don't want a tool that tries to second guess me, hides things from me, etc.
One Access-like app is OpenOffice.org 2.0 Base (Go test it and report issues before the final OpenOffice.org 2.0 release!). It's extremely new and it's rough around the edges, but it looks decent. It's an Access clone to the point where I'm surprised Microsoft aren't suing about stolen icons.
If you're looking for something in the same vein, but not seeking a direct Access rip-off, then Rekall may be an option worth investigating. Both it an OO.o are cross-platform.
Do be aware that tools like Access encourage you to do too much client-side. It's important to consider using in-database stored procedures and (often updateable) views where appropriate for efficiency and clean structure. You can then use an Access-like app to provide a user-interface to that higher level database interface, instead of just poking around in the raw tables.
That's reasonable for some very high level subsystems in the kernel. For most things, such as drivers, the scheduler, etc, it's probably not.
Sometimes defining "pass" and "fail" is hard enough, with tuning efforts. Then there's cleanups. On top of that there are fixes to obsure drivers for hardware that nobody on LKML actually has.
I'm all for unit test based development, but there are some levels where it's practical, and some where I don't think it is. An OS kernel is to an extent the impractical side. I do like the idea of unit-tests from userspace to make sure nothing userspace-visible breaks, though.
You're joking ... but it's not entirely a joke. The fact is that as a user who wants flexibility and customisation from my UI, in many ways I find KDE more friendly than the Mac OS X Finder. I find that Mac OS X's UI significantly hinders my ability to work quickly and effectively.
... my point is that "user friendly" to one person can be user hostile to another.
Yes, that's just a personal thing. Yes, most users are the opposite. Still
The site does appear cleaner visually as well, which is nice. The comments post page in particular is much neater and nicer. I'm absolutely overjoyed to find little or no use of "px" for fonts in the style sheets - and thus, I can finally read slashdot without having to force the font size up first. That'll make users with poor vision, and those with extremely high res monitors, very happy.
... kudos to the slashcode team. I know how hard cleanups (and presumably lots of refactoring behind the scenese) like this are.
So
FTP and client-side encryption is a bit of an icky hack though. It also doesn't protect your FTP session from attack (password theft, use of the FTP server for storing things you don't know about, etc).
I'd be waaay happier with WebDAV and client certs. It's a similar concept, in terms of being remote file storage, but is much more secure and lacks the headache-inducing pain of FTP. No firewall problems either, since it's plain 'ol HTTPs as far as the firewall / proxy is concerned.
I went poking around the site trying to find out what it supports in terms of roaming. Being able to just pull down a .jar from anywhere, and have a writeable LDAP+TLS address book, IMAP+TLS mail (both protected by SSL clent certs), etc all preconfigured would just be bliss.
Right now, it's hard enough to find a client that supports writeable LDAP address books at all, let alone usably and with TLS and client cert support.
Alas, their website doesn't seem to have any sort of feature summary, so it's rather hard to say w/o grabbing and trying it out.
Yes, it's a difficult situation where your control is limited and those running the other parts of the system aren't concerned about the issues or willing to listen.
:-)
As for the network, if you do get the chance then a good stackable managed switch (ie backplane stacking , not connect-the-uplinks) with serial console is your best friend