Well said. The biggest flaw in the ODF standard as its stands is that it doesn't really use XML's capabilities for, well, extensibility. There is no way in ODF to include your own data with your own schema (in a separate namespace) and have OO.o preserve that data, keep it with the appropraite document elements, delete it if the associated document elements are deleted, and so on. Let alone anything so interesting as interact with it or access it via plug-ins or extensions to add new capabilities.
The ODF spec gives almost no consideration to the perservation and manipulation of third party markup. OO.o currently just discards it silently when loading a document, and the saved copy omits any unrecognised markup.
The MS Office formats do offer all these features, and for that reason alone I'm starting to hope MS wins this one. Both formats seem like uninspring choices for different reasons, but at least the MS one won't artificially limit features and give the "universal" format the reputation of being limited, unreliable for more than basic uses, and crap.
I'm actually really interested in the new Office features for embedded third party markup and interaction with it via forms, etc. It has some interesting possibilities for use at work and with some other tools I'm involved with, and it's something I'd very much like to expore. If OO.o could support the same capabilities I'd be a very happy man, but I just don't see it happening.
Lots. One that's not specific to the file formats, though probably affected by them, is performance. OO.o can be very slow at accomplishing common tasks, particularly loading and saving files. I am constantly amazed as I use OO.o day-to-day by how much RAM it manages to use on simple documents, and how long they can take to open and save. I have it sitting beside MS Office, so I can make a very direct comparison on the same hardware and OS. There are lots of things I do like about OO.o, but its performance is not one of those things.
Beyond that, I can't say there's too much I've run into that I can do in Office but not OO.o . A lot of things are much smoother in Office, though... one could argue that except where OO.o has gone and done something new and intersting, most of its UI is a bad clone of an old version of a bad UI (Office '97). Office has moved on, and while its UI is still pretty poor, it's a lot better than it was... but OO'o's really hasn't moved much. Frankly, it sucks badly to use, and that's despite my being more familiar with OO.o than Office.
I think MS's argument is a lot weaker with regards to the file format, though I'm certainly no expert. I do expect that they'll be able to implement their own formats with better performance in Office than the ODF formats, but that's hardly surprising given that they designed them with that as one of their key goals.
More interestingly, the Office XML formats require implementing programs to preserve unrecognised valid markup from other namespaces. This lets you do things like embed (eg) an order record in an Office document, embed a JDF specification (when Publisher gets around to going XML as well), and so on. It's not exciting for the end user, but for developers and larger businesses it's a really nice thing to see. One could argue that Microsoft are getting XML "right" in a way that few have so far. Most interestingly by far, you can link the foreign markup in to your Office documents, so that (eg) a user can fill in a form in a document that's actually an XForm with your own structured data. Alternately, a newspaper could insert some custom metadata when exporting stories from a database, so it can tell what's been done with it, keep the DB up to date when the story is imported again, and so on. It's quite interesting stuff. Check out Brian Jones' weblog for some interesting use cases and discussion (and some persistent questions about the licensing issues from me).
The ODF spec only briefly refers to this issue at all. IIRC it permits apps to do this perservation, but does not require it or provide any facilities to support it. If apps aren't required to preserve your markup, then in my view it's not much darn good - it's somewhat like saying that apps may preserve your document text and structure. OpenOffice doesn't preserve foreign markup at all. If it's not directly in the ODF spec, you can't use it. This really loses one of the great advantages that XML has, and is very disappointing.
If we had a standard office document format that I could rely on having these features, there are some very interesting things I could do with it, especially at work. This fragementation and the ODF limitations are extremely frustrating, especially given that the ODF folks are always banging on the XML gong while missing one of the key abilities of XML entirely.
I think MS screwed up very badly at the start by attacking ODF with rhetoric and poorly thought out garbage, not a solid arguement over capabilities and other real issues. Insufficient audiovisual support indeed...
Personally I don't care much whether ODF or MS Office XML wins, so long as the resulting standard:
can be reasonably supported in all office-style apps
isn't too much of a moving target
is royalty free, including automatic royalty free licenses on any required patents
is controlled by a standards body
specifies enough core functionality that incompati
I'm not sure about that. It's a balance - is it worth the frustration of finding something, downloading it, finding it's a crappy rip / encoding, trying again, etc etc, when it's cheap and easy to buy? Perhaps, perhaps not. Depends on how much money you have, how much time you have, and other things.
That blance changes when the good to be acquired is (a) expensive relative to perceived value; (b) more of a pain to get, eg requires a special tri to a store; (c) possibly not even available legitimately yet; (d) annoying to legally buy online (crappy website, subscription only, bad payment methods, high prices, special client software, DRM, can't use it on a music player, etc)... probably other things too.
I'm not arguing that people won't download illegally if they're given decent options. I just think fewer will, and the record companies will salvage some sales, though possibly at the cost of reduced value from existing legit customers. Worth it? Don't know - but I think they're insane not to start experimenting.
It wouldn't really be a very good experiment, because it'd influence its self in a way that would not hold when extrapolated to a larger sample group. "Stop the presses! Movie studio releases big-name film for free download off its website!"
Were I a film studio exec, I sure wouldn't release it for free - but I'd almost certainly make it a cheap download, then bask in the glorious publicity and profits. I'd probably keep on doing it too... but I'm not sure the industry as a whole would gain (in financial terms) if they _all_ did it with _all_ films, thus removing the differentiating factor.
Personally, I think free-for-download films are nonsense given their present production costs etc. The same is not true for quite a bit (but not all, see production cost) music, where money can be made from ticket sales at concerts, extras, etc etc. I think music co's are insane not to release some inventory for free - like a few tracks (not DRM'd, you want them shared, and full high-quality copies) from each album, then offer the rest available for affordable, convenient download. To a large extent that's a cultural issue in the companies, I suspect, combined with a lot of fear. That model has been working well for quite a lot of folks now, but it's still foreign and scary and different. We'll see what happens as the squeeze grows.
And if the music company had a link from the band/album info page to an easy-to-download version, DRM-free, at a reasonable cost?
Chances are the first person would've bought it - P2P networks are a major PITA after all. The music co would get a sale. One more than they'd get otherwise, even if the other 10 people do copy the damn thing.
I suspect they're going to have to scale back their expectations (perhaps they just can't keep on selling CDs for AU$30 like they still try to here) and adapt to changing consumer desires, while trying to preserve the core of their business and find additional revenue sources and business opportunities. Wow, like a real business has to.
In fairness, a crook can also DoS my car by taking a hammer to the engine, sticking putty in the locks, etc... so I guess I'm no worse off. You know what they say about physical access.
At least the keyless systems do seem to slow them down a little more.
Fantastic, so now a crook can DoS my car by trying to authenticate too many times, and I have to send a part back to the factory for reprogramming if they do?
This doesn't sound so DIY at all. I just don't think the submitter understood the extent to which most people consider a computer a complete unit (these are the folks who turn off the screen to turn off the computer).
It sounds like they're only doing DIY in the sense of package customisation, a-la Dell. We're not talking motherboards, memory, and swearing about clearance between the RAM slots and the video card here. More "I'll have that P4/2GB/200MB with that 19 inch LCD, that wireless keyboard and mouse, and, oh, I'll upgrade the disk to 500GB too, can you do that for me now?".
I quote:
"With the build-your-own-computer counters, shoppers can choose between several different components.
"Such components include central processing units -- the brain of the computer that powers its basic functions -- as well as monitors, keyboards and mice that customers can combine to create customized packages they can load in a shopping cart and take home right away."
In other words, "where's the news"? This doesn't sound much more interesting than what (eg) Dell have been doing for donkeys, except for the impulse-buy aspect.
I don't think that's a good solution. It'd be an adquate half-measure, but would sacrifice:
- flexibility for the kernel team
- non-x86 users' choices... and it'd make the kernel a heck of a lot harder to debug when issues _do_ come up. Ugh.
I'd be all for it, except that accepting that option now would lock everyone into it almost indefinitely - and I *don't* want to be stuck with that situation down the track. Of course, the current option sucks even more, so I'll admit to being somewhat ambivalent.
I do think you may be confusing the types of licensing involved here. Many of the required licenses are patent licenses, and don't have to conflict with open source distribution. I do expect that most of these drivers will include 3rd-party licensed libraries and components as well, so I don't personally see any way a graphics card mfgr could "open" existing drivers. I don't see why an underdog with nothing much to lose like S3 can't do it as a play for market share. Let's face it - they don't have much to protect. Their technology is behind, verging on crap, and they don't need to fear ATi or NVidia poaching ideas. The only likely threat is IP-related ("Hey, now that we can see your source we can see that you're using $patent-technology-x, pay up)... and I'm not convinced that can't be avoided.
Were I NVidia, there's no chance I'd ever open my drivers. They're a huge asset to NVidia, and probably contain lots of juicy sue-able goodness. If I were ATi, I'd be more inclined to think about it - since the ATi drivers are *complete* *crap*... but would be concerned about making it easier to explore the underlying workings of the card (if I felt those were an important secret) through the now-exposed driver/hw interface, and would still be concerned about legal issues. If I were S3, I'd seriously think about developing new, clean drivers and opening them up... or just publishing *full* hardware specs and seeing what happened. S3 long ago licensed out its few scraps of interesting tech, and they're not going to catch up to NVidia and ATi on R&D, so they need another angle.
That's fascinating. I actually thought the frequencies were the other way around, but this article (http://hometheater.about.com/cs/television/a/aavi deoresa.htm) set me straight. PAL and SECAM are lower frequency but higher resolution than the US NTSC format.
Sadly, when it comes to consoles, "only badly made games" is quite likely to encompass a lot of them. Especially once they figured out that crappy delay loops might let them work around display timing issues... ugh. I still see software written/now/ that has delay timer loops, though usually only by people I wouldn't trust to babysit a rock in a sand pit.
Consoles encourage the old school method of timer programming:
for (int i = 0; i < SOME_BIG_NUMBER; i++) { int fakeval = 0; }
In fact, I don't know how many consoles, especially old consoles, would even have a system timer, let alone one (a) sufficiently high resolution and (b) with low enough access costs to make it practical to use for game timings.
Anybody remember the "turbo" button - ie the "underclock my PC when this is off" button? That was necessary for older games written for the 80386 that assumed a small range of clock frequencies and did delays that way. You'll run into the same issue with this console - it's going to be like turning "turbo" on for an old game. Well, probably.
Cool, I didn't know that. It still looks very limited - can't actually reliably copy or delete a whole tree of files - but it's a lot better than anything I'd seen before.
Limited and read-only, with very dangerous write support. NTFS has only been partially reverse engineered, and is incredibly complex.
Now, I'd like to be able to access NTFS from other platforms, but in truth I'd be much happer with a cross-platform file system standard for data interchange etc that everyone could agree on... but wasn't as crap as FAT32.
I'd argue that FAT32 is awful for essentially everything, we just have to use it for some things anyway. Consider removable media - they need to be *reliable* and *robust*, which fat32 is not. Any modern file system would be better... but there's no other read/write FS that Windows, Mac OS X, and Linux can agree to read and write on any media type (ie not ISO9660/UDF because most only support it on optical media).
FAT32 is dangerously fragile, is very slow in real world use - consider how fast it fragments compared to a modern FS - has very limited partition sizes, and has no provision for any sort of file extended attributes, security controls, etc. It's horrible.
I must certainly agree that if you're still using it for your primary partition, you're probably making a big mistake.
The matter of the UI toolkit is partly a matter of taste. There are certainly areas where gtk+ and Qt are inferior to other implementations, but I don't think it's as drastic as you make out, nor do I think that cloning the Apple UI is the correct solution. I actually find getting around the Mac UI somewhat painful at times, and I think you'll find that a large part of the problem you're encountering stems from familiarity and taste (especially WRT appearance).
If there are specific instances where behaviour changes would improve usability, please submit suggestions to the gtk+ team and to TrollTech. Suggesting a wholesale "research and rip off" of the Mac OS X GUI is neither helpful, nor likely to ever happen.
I've been using Eiffel - and EiffelStudio - a bit lately. Eiffel seems like a decent enough language, though it's most attractive for writing libraries etc, just where its less than fantastic interface with other languages makes it less useful. If I didn't feel some bizarre need to have portable code (what a silly idea!) I'd be interested in using it on the.NET CLR... but that's not viable for me at present.
EiffelStudio is nowhere near as nice as Eiffel. The IDE is clunky and in some ways quite antiquated. A good gcc Eiffel backend (NOT intermediate-C based like SmartEiffel) or a standalone compiler combined with good integration into Eclipse, VC++, and so on would be much more interesting IMO. Add the ability to generate interface stubs for C, C++, and Java, and it'd actually start to look attractive.
Right now, though, Eiffel looks like the kind of language you use in isolated projects where you don't need to use too many outside componenents and don't expect to have others basing work on your code. Does that sort of project still even exist?
With the latest MS Office XML license, I don't think there's any chance royalties might be required. The only real remaining issue is that the license doesn't make much of a guarantee about future versions, but IIRC MS released a binding statement addressing this. I would have to go and hunt up the details now to be 100% sure. Just be aware that there's a LOT of outdated information and misconceptions about what they're doing (and they didn't help by ignoring many questions for long periods, giving roundabout answers, etc).
The only thing I'd really be worried about these days is who controls the format into the future.
Memory stick does have one thing going for it - it's fairly robust. I've seen those things take abuse that's hard to believe, and still work. When compared to CompactFlash, they're WAY tougher, and these days they don't cost that much more (now that SanDisk etc can make them, ie no Sony media monopoly). That said, they're no better than SD media or the even newer and smaller form factors making headway into the market now.
Memory Stick was another Sony attempt to get a hold on the market with a non-interoperable product that forces users to buy all-Sony devices, then buy overpriced media off Sony. Surprise surprise, it didn't work. When will they learn?
You can specify fonts in pt, but they'll be rendered as if they were going to a 72dpi display. The DDC display information is ignored. This means that unless you actually have a 72dpi display the fonts will be too small (or large, if it's lower res, but that's unlikely). Because of this app designers on Windows have got used to assuming that a given font will be a given pixel size in all cases, and combined with their lazy use of static layouts this results in dialogs, menus, etc that break when the font sizes change.
If they obeyed the DDC info (but provideded an ovverride for those displays that send bogus information - "windows doesn't use it, so we can just put whatever the cat threw up in those bytes, right?") and provided a civilized dynamic layout manager like every other toolkit has been using almost exclusively for nearly 10 years, things would suck a lot less. But for backward compatibility they can't.
This UI change is an opportunity to ensure that new apps based on their new declarative XML UI language and using their 3D UI will get these things right.
Like in many things, I suspect it's the negative stuff that gets noticed. That, and the fact that there are a HUGE number of immature geeks on slashdot. I'm not slamming the whole crowd here... but with this many people and anonymity you'll get a lot of gits turning up.
I cringe at comments quite frequently, but there's just nothing to be done beyond grimace and stagger onward. In an anonymous online situation the chances are that if they said something dodgy in the first place they're not going to care if you pull them up on it.
Why would anyone care about this? The moment you get a new OS installed (be it Windows or Linux), the first thing you do is tweak Control Panel-type settings to adjust fonts, etc. Sure, on Linux and X, fonts can sometimes be a pain but Windows is pretty good with maintaining a standard look with fonts afterwards. I can't recall one time when I've worried about "dpi" settings on Windows. </i>
Then you either have a low-resolution monitor, very good eyesight, or don't work on the computer that much (and since you're on slashdot, like myself, we can discount the last option). A 120dpi display with an OS displaying fonts on it as if it were 72dpi gets REALLY annoying, as fonts and other on-screen elements are displayed at slightly over HALF their intended size. This is made especially bad when some batbrain web designer decides that 9pt looks good and is readable in high-res gloss print, so it must on screen too...
Trust me, the normal user should care about this one. Many of the users at my work do, as few have perfect vision. My workplace is not particularly unusual, though it does have more 40-50 year old people than many. I had one visually impaired girl at work who I had to move onto a Linux desktop solely so I could get her a display that had fonts big enough for her to work on. The only alternatives for win32 were clumsy screen magnification schemes, or setting the display resolution to 640x480 on her 21" display (making most apps essentially unusable by lack of screen real-estate).
Large fonts on Windows is badly broken (many apps' UIs break significantly, and even the Windows UI falls apart in many places - badly scaled buttons and icons, dialog buttons that stick off the edge of the dialog, etc). For a user working on a 130dpi laptop display like mine, this is indescribably bad. Even with good vision you're still squinting to see what the heck is going on sometimes, and some of the users at work look at my laptop under Windows and say "how can you read that!". On a laptop or other LCD display, it's not like lowering the resolution (a pathetic workaround anyway) is a viable option.
So, yes, it does matter. If you like to work comfortably with text for long periods on a modern display, want crisp and smooth but readable text on your high-res CRT, or use an ultra-high-res display device, Windows' handling of resolution is an incredible pain. Just to make things more fun, if you _do_ tell it a correction factor, it applies it to printer output too (since it's all done via GDI) so your printed documents come out the wrong godamm sizes.
<i>Again, why does a normal user care about this? The Explorer look and feel has it's problems, sure, but is it not the case that most people have got used to it's limitations and are now fairly happy with the 2D UI and way of working? We're constantly being told that Windows users don't like change - which is why they don't use Linux or OpenOffice - so why are they going to jump to use a new 3D UI and have to learn from the beginning again?</i>
I don't like the dramatic user-visible changes in the UI. I do think, however, that the underlying mechanism change to a GPU-based composited UI brings real benefits in terms of window redraws, handling blocked windows, and many other things. It also lets you do smarter previewing in alt-tab and other touches that don't dramatically re-work the UI, just enhance it. Of course, that doesn't mean MS will go that way.
<i>I agree but the two examples you've given are minor reasons for upgrading to Vista, if they are reasons at all, and this is my point. Apart from focusing more on security and stability, MS have probably reached an endpoint with features on Windows.</i>
In the core operating system as visible to an end user at home, probably so. They have a LONG way to go in security and stability, as well as driver safety, OS maintainance, network administration, general transparent network integration, ease of use and convenience, out-of-the-box util
Actually, I disagree. The interface is not entirely useless, in that they've used it as an opportunity to fix many of the things wrong with the old Windows UI. The outstanding key issue is resolution dependence - with Vista, a 12pt font should finally be a 12pt font, not "whatever 12pt is at 72dpi, in pixels, no matter what your real display res is". And don't suggest setting "large fonts" or worse setting the font res option to your actual display res - as the rest of the UI is all statically laid out, it chokes rather badly.
A 3D UI also makes doing interesting things with window management easier, or in fact practical.
IMO this is an opportunity for MS to do a lot right, and certainly isn't useless.
I'd like to disagree, but with the growing promenance of organized crime, highly profitable spam, and so on, I can't. I'm mildly surprised that one of the bigger organizations hasn't gone out and found someone who can do what they need and has few scruples about doing it when the money is right.
I can only assume that it's not worth doing - ie systems to crack are in such plentiful supply already that there's just no need to bother with real effort.
This is where Xen support for Mac OS X would rock. With a VT-enabled CPU (the coming Core Duos should be) it'd be possible to run Windows and Mac OS X side by side. Xen can also handle all the legacy BIOS emulation, etc.
Sounds nice, eh? Like you said, potentially just a hotkey to switch. It'd be harder to do if you wanted accelerated 3D etc but I doubt it's impossible. I'd be surprised if the TPM chip got in the way either.
For this to work really well it'd need support from Apple, and alas that pretty much means it won't happen thanks to the joys of Not Invented Here (TM).
Slashdot Mirror
Well said. The biggest flaw in the ODF standard as its stands is that it doesn't really use XML's capabilities for, well, extensibility. There is no way in ODF to include your own data with your own schema (in a separate namespace) and have OO.o preserve that data, keep it with the appropraite document elements, delete it if the associated document elements are deleted, and so on. Let alone anything so interesting as interact with it or access it via plug-ins or extensions to add new capabilities.
The ODF spec gives almost no consideration to the perservation and manipulation of third party markup. OO.o currently just discards it silently when loading a document, and the saved copy omits any unrecognised markup.
The MS Office formats do offer all these features, and for that reason alone I'm starting to hope MS wins this one. Both formats seem like uninspring choices for different reasons, but at least the MS one won't artificially limit features and give the "universal" format the reputation of being limited, unreliable for more than basic uses, and crap.
I'm actually really interested in the new Office features for embedded third party markup and interaction with it via forms, etc. It has some interesting possibilities for use at work and with some other tools I'm involved with, and it's something I'd very much like to expore. If OO.o could support the same capabilities I'd be a very happy man, but I just don't see it happening.
Beyond that, I can't say there's too much I've run into that I can do in Office but not OO.o . A lot of things are much smoother in Office, though
I think MS's argument is a lot weaker with regards to the file format, though I'm certainly no expert. I do expect that they'll be able to implement their own formats with better performance in Office than the ODF formats, but that's hardly surprising given that they designed them with that as one of their key goals.
More interestingly, the Office XML formats require implementing programs to preserve unrecognised valid markup from other namespaces. This lets you do things like embed (eg) an order record in an Office document, embed a JDF specification (when Publisher gets around to going XML as well), and so on. It's not exciting for the end user, but for developers and larger businesses it's a really nice thing to see. One could argue that Microsoft are getting XML "right" in a way that few have so far. Most interestingly by far, you can link the foreign markup in to your Office documents, so that (eg) a user can fill in a form in a document that's actually an XForm with your own structured data. Alternately, a newspaper could insert some custom metadata when exporting stories from a database, so it can tell what's been done with it, keep the DB up to date when the story is imported again, and so on. It's quite interesting stuff. Check out Brian Jones' weblog for some interesting use cases and discussion (and some persistent questions about the licensing issues from me).
The ODF spec only briefly refers to this issue at all. IIRC it permits apps to do this perservation, but does not require it or provide any facilities to support it. If apps aren't required to preserve your markup, then in my view it's not much darn good - it's somewhat like saying that apps may preserve your document text and structure. OpenOffice doesn't preserve foreign markup at all. If it's not directly in the ODF spec, you can't use it. This really loses one of the great advantages that XML has, and is very disappointing.
If we had a standard office document format that I could rely on having these features, there are some very interesting things I could do with it, especially at work. This fragementation and the ODF limitations are extremely frustrating, especially given that the ODF folks are always banging on the XML gong while missing one of the key abilities of XML entirely.
I think MS screwed up very badly at the start by attacking ODF with rhetoric and poorly thought out garbage, not a solid arguement over capabilities and other real issues. Insufficient audiovisual support indeed...
Personally I don't care much whether ODF or MS Office XML wins, so long as the resulting standard:
I'm not sure about that. It's a balance - is it worth the frustration of finding something, downloading it, finding it's a crappy rip / encoding, trying again, etc etc, when it's cheap and easy to buy? Perhaps, perhaps not. Depends on how much money you have, how much time you have, and other things.
That blance changes when the good to be acquired is (a) expensive relative to perceived value; (b) more of a pain to get, eg requires a special tri to a store; (c) possibly not even available legitimately yet; (d) annoying to legally buy online (crappy website, subscription only, bad payment methods, high prices, special client software, DRM, can't use it on a music player, etc)... probably other things too.
I'm not arguing that people won't download illegally if they're given decent options. I just think fewer will, and the record companies will salvage some sales, though possibly at the cost of reduced value from existing legit customers. Worth it? Don't know - but I think they're insane not to start experimenting.
It wouldn't really be a very good experiment, because it'd influence its self in a way that would not hold when extrapolated to a larger sample group. "Stop the presses! Movie studio releases big-name film for free download off its website!"
... but I'm not sure the industry as a whole would gain (in financial terms) if they _all_ did it with _all_ films, thus removing the differentiating factor.
Were I a film studio exec, I sure wouldn't release it for free - but I'd almost certainly make it a cheap download, then bask in the glorious publicity and profits. I'd probably keep on doing it too
Personally, I think free-for-download films are nonsense given their present production costs etc. The same is not true for quite a bit (but not all, see production cost) music, where money can be made from ticket sales at concerts, extras, etc etc. I think music co's are insane not to release some inventory for free - like a few tracks (not DRM'd, you want them shared, and full high-quality copies) from each album, then offer the rest available for affordable, convenient download. To a large extent that's a cultural issue in the companies, I suspect, combined with a lot of fear. That model has been working well for quite a lot of folks now, but it's still foreign and scary and different. We'll see what happens as the squeeze grows.
And if the music company had a link from the band/album info page to an easy-to-download version, DRM-free, at a reasonable cost?
Chances are the first person would've bought it - P2P networks are a major PITA after all. The music co would get a sale. One more than they'd get otherwise, even if the other 10 people do copy the damn thing.
I suspect they're going to have to scale back their expectations (perhaps they just can't keep on selling CDs for AU$30 like they still try to here) and adapt to changing consumer desires, while trying to preserve the core of their business and find additional revenue sources and business opportunities. Wow, like a real business has to.
In fairness, a crook can also DoS my car by taking a hammer to the engine, sticking putty in the locks, etc... so I guess I'm no worse off. You know what they say about physical access.
At least the keyless systems do seem to slow them down a little more.
Fantastic, so now a crook can DoS my car by trying to authenticate too many times, and I have to send a part back to the factory for reprogramming if they do?
Give me my keys back.
This doesn't sound so DIY at all. I just don't think the submitter understood the extent to which most people consider a computer a complete unit (these are the folks who turn off the screen to turn off the computer).
It sounds like they're only doing DIY in the sense of package customisation, a-la Dell. We're not talking motherboards, memory, and swearing about clearance between the RAM slots and the video card here. More "I'll have that P4/2GB/200MB with that 19 inch LCD, that wireless keyboard and mouse, and, oh, I'll upgrade the disk to 500GB too, can you do that for me now?".
I quote:
In other words, "where's the news"? This doesn't sound much more interesting than what (eg) Dell have been doing for donkeys, except for the impulse-buy aspect.
I don't think that's a good solution. It'd be an adquate half-measure, but would sacrifice: ... and it'd make the kernel a heck of a lot harder to debug when issues _do_ come up. Ugh.
... and I'm not convinced that can't be avoided.
... but would be concerned about making it easier to explore the underlying workings of the card (if I felt those were an important secret) through the now-exposed driver/hw interface, and would still be concerned about legal issues. If I were S3, I'd seriously think about developing new, clean drivers and opening them up ... or just publishing *full* hardware specs and seeing what happened. S3 long ago licensed out its few scraps of interesting tech, and they're not going to catch up to NVidia and ATi on R&D, so they need another angle.
- flexibility for the kernel team
- non-x86 users' choices
I'd be all for it, except that accepting that option now would lock everyone into it almost indefinitely - and I *don't* want to be stuck with that situation down the track. Of course, the current option sucks even more, so I'll admit to being somewhat ambivalent.
I do think you may be confusing the types of licensing involved here. Many of the required licenses are patent licenses, and don't have to conflict with open source distribution. I do expect that most of these drivers will include 3rd-party licensed libraries and components as well, so I don't personally see any way a graphics card mfgr could "open" existing drivers. I don't see why an underdog with nothing much to lose like S3 can't do it as a play for market share. Let's face it - they don't have much to protect. Their technology is behind, verging on crap, and they don't need to fear ATi or NVidia poaching ideas. The only likely threat is IP-related ("Hey, now that we can see your source we can see that you're using $patent-technology-x, pay up)
Were I NVidia, there's no chance I'd ever open my drivers. They're a huge asset to NVidia, and probably contain lots of juicy sue-able goodness. If I were ATi, I'd be more inclined to think about it - since the ATi drivers are *complete* *crap*
That's fascinating. I actually thought the frequencies were the other way around, but this article (http://hometheater.about.com/cs/television/a/aavi deoresa.htm) set me straight. PAL and SECAM are lower frequency but higher resolution than the US NTSC format.
/now/ that has delay timer loops, though usually only by people I wouldn't trust to babysit a rock in a sand pit.
Sadly, when it comes to consoles, "only badly made games" is quite likely to encompass a lot of them. Especially once they figured out that crappy delay loops might let them work around display timing issues... ugh. I still see software written
Consoles encourage the old school method of timer programming:
for (int i = 0; i < SOME_BIG_NUMBER; i++) { int fakeval = 0; }
In fact, I don't know how many consoles, especially old consoles, would even have a system timer, let alone one (a) sufficiently high resolution and (b) with low enough access costs to make it practical to use for game timings.
Anybody remember the "turbo" button - ie the "underclock my PC when this is off" button? That was necessary for older games written for the 80386 that assumed a small range of clock frequencies and did delays that way. You'll run into the same issue with this console - it's going to be like turning "turbo" on for an old game. Well, probably.
Cool, I didn't know that. It still looks very limited - can't actually reliably copy or delete a whole tree of files - but it's a lot better than anything I'd seen before.
Limited and read-only, with very dangerous write support. NTFS has only been partially reverse engineered, and is incredibly complex.
Now, I'd like to be able to access NTFS from other platforms, but in truth I'd be much happer with a cross-platform file system standard for data interchange etc that everyone could agree on... but wasn't as crap as FAT32.
Sadly I don't see it happening.
I'd argue that FAT32 is awful for essentially everything, we just have to use it for some things anyway. Consider removable media - they need to be *reliable* and *robust*, which fat32 is not. Any modern file system would be better ... but there's no other read/write FS that Windows, Mac OS X, and Linux can agree to read and write on any media type (ie not ISO9660/UDF because most only support it on optical media).
FAT32 is dangerously fragile, is very slow in real world use - consider how fast it fragments compared to a modern FS - has very limited partition sizes, and has no provision for any sort of file extended attributes, security controls, etc. It's horrible.
I must certainly agree that if you're still using it for your primary partition, you're probably making a big mistake.
Aaah, if only MS would publish the NTFS specs...
X?
The X Window System / X11?
Mac OS X?
X marks the spot?
wha?
The matter of the UI toolkit is partly a matter of taste. There are certainly areas where gtk+ and Qt are inferior to other implementations, but I don't think it's as drastic as you make out, nor do I think that cloning the Apple UI is the correct solution. I actually find getting around the Mac UI somewhat painful at times, and I think you'll find that a large part of the problem you're encountering stems from familiarity and taste (especially WRT appearance).
If there are specific instances where behaviour changes would improve usability, please submit suggestions to the gtk+ team and to TrollTech. Suggesting a wholesale "research and rip off" of the Mac OS X GUI is neither helpful, nor likely to ever happen.
I've been using Eiffel - and EiffelStudio - a bit lately. Eiffel seems like a decent enough language, though it's most attractive for writing libraries etc, just where its less than fantastic interface with other languages makes it less useful. If I didn't feel some bizarre need to have portable code (what a silly idea!) I'd be interested in using it on the .NET CLR ... but that's not viable for me at present.
EiffelStudio is nowhere near as nice as Eiffel. The IDE is clunky and in some ways quite antiquated. A good gcc Eiffel backend (NOT intermediate-C based like SmartEiffel) or a standalone compiler combined with good integration into Eclipse, VC++, and so on would be much more interesting IMO. Add the ability to generate interface stubs for C, C++, and Java, and it'd actually start to look attractive.
Right now, though, Eiffel looks like the kind of language you use in isolated projects where you don't need to use too many outside componenents and don't expect to have others basing work on your code. Does that sort of project still even exist?
With the latest MS Office XML license, I don't think there's any chance royalties might be required. The only real remaining issue is that the license doesn't make much of a guarantee about future versions, but IIRC MS released a binding statement addressing this. I would have to go and hunt up the details now to be 100% sure. Just be aware that there's a LOT of outdated information and misconceptions about what they're doing (and they didn't help by ignoring many questions for long periods, giving roundabout answers, etc).
The only thing I'd really be worried about these days is who controls the format into the future.
Memory stick does have one thing going for it - it's fairly robust. I've seen those things take abuse that's hard to believe, and still work. When compared to CompactFlash, they're WAY tougher, and these days they don't cost that much more (now that SanDisk etc can make them, ie no Sony media monopoly). That said, they're no better than SD media or the even newer and smaller form factors making headway into the market now.
Memory Stick was another Sony attempt to get a hold on the market with a non-interoperable product that forces users to buy all-Sony devices, then buy overpriced media off Sony. Surprise surprise, it didn't work. When will they learn?
You can specify fonts in pt, but they'll be rendered as if they were going to a 72dpi display. The DDC display information is ignored. This means that unless you actually have a 72dpi display the fonts will be too small (or large, if it's lower res, but that's unlikely). Because of this app designers on Windows have got used to assuming that a given font will be a given pixel size in all cases, and combined with their lazy use of static layouts this results in dialogs, menus, etc that break when the font sizes change.
If they obeyed the DDC info (but provideded an ovverride for those displays that send bogus information - "windows doesn't use it, so we can just put whatever the cat threw up in those bytes, right?") and provided a civilized dynamic layout manager like every other toolkit has been using almost exclusively for nearly 10 years, things would suck a lot less. But for backward compatibility they can't.
This UI change is an opportunity to ensure that new apps based on their new declarative XML UI language and using their 3D UI will get these things right.
Like in many things, I suspect it's the negative stuff that gets noticed. That, and the fact that there are a HUGE number of immature geeks on slashdot. I'm not slamming the whole crowd here ... but with this many people and anonymity you'll get a lot of gits turning up.
I cringe at comments quite frequently, but there's just nothing to be done beyond grimace and stagger onward. In an anonymous online situation the chances are that if they said something dodgy in the first place they're not going to care if you pull them up on it.
Why would anyone care about this? The moment you get a new OS installed (be it Windows or Linux), the first thing you do is tweak Control Panel-type settings to adjust fonts, etc. Sure, on Linux and X, fonts can sometimes be a pain but Windows is pretty good with maintaining a standard look with fonts afterwards. I can't recall one time when I've worried about "dpi" settings on Windows.
</i>
Then you either have a low-resolution monitor, very good eyesight, or don't work on the computer that much (and since you're on slashdot, like myself, we can discount the last option). A 120dpi display with an OS displaying fonts on it as if it were 72dpi gets REALLY annoying, as fonts and other on-screen elements are displayed at slightly over HALF their intended size. This is made especially bad when some batbrain web designer decides that 9pt looks good and is readable in high-res gloss print, so it must on screen too...
Trust me, the normal user should care about this one. Many of the users at my work do, as few have perfect vision. My workplace is not particularly unusual, though it does have more 40-50 year old people than many. I had one visually impaired girl at work who I had to move onto a Linux desktop solely so I could get her a display that had fonts big enough for her to work on. The only alternatives for win32 were clumsy screen magnification schemes, or setting the display resolution to 640x480 on her 21" display (making most apps essentially unusable by lack of screen real-estate).
Large fonts on Windows is badly broken (many apps' UIs break significantly, and even the Windows UI falls apart in many places - badly scaled buttons and icons, dialog buttons that stick off the edge of the dialog, etc). For a user working on a 130dpi laptop display like mine, this is indescribably bad. Even with good vision you're still squinting to see what the heck is going on sometimes, and some of the users at work look at my laptop under Windows and say "how can you read that!". On a laptop or other LCD display, it's not like lowering the resolution (a pathetic workaround anyway) is a viable option.
So, yes, it does matter. If you like to work comfortably with text for long periods on a modern display, want crisp and smooth but readable text on your high-res CRT, or use an ultra-high-res display device, Windows' handling of resolution is an incredible pain. Just to make things more fun, if you _do_ tell it a correction factor, it applies it to printer output too (since it's all done via GDI) so your printed documents come out the wrong godamm sizes.
<i>Again, why does a normal user care about this? The Explorer look and feel has it's problems, sure, but is it not the case that most people have got used to it's limitations and are now fairly happy with the 2D UI and way of working? We're constantly being told that Windows users don't like change - which is why they don't use Linux or OpenOffice - so why are they going to jump to use a new 3D UI and have to learn from the beginning again?</i>
I don't like the dramatic user-visible changes in the UI. I do think, however, that the underlying mechanism change to a GPU-based composited UI brings real benefits in terms of window redraws, handling blocked windows, and many other things. It also lets you do smarter previewing in alt-tab and other touches that don't dramatically re-work the UI, just enhance it. Of course, that doesn't mean MS will go that way.
<i>I agree but the two examples you've given are minor reasons for upgrading to Vista, if they are reasons at all, and this is my point. Apart from focusing more on security and stability, MS have probably reached an endpoint with features on Windows.</i>
In the core operating system as visible to an end user at home, probably so. They have a LONG way to go in security and stability, as well as driver safety, OS maintainance, network administration, general transparent network integration, ease of use and convenience, out-of-the-box util
Actually, I disagree. The interface is not entirely useless, in that they've used it as an opportunity to fix many of the things wrong with the old Windows UI. The outstanding key issue is resolution dependence - with Vista, a 12pt font should finally be a 12pt font, not "whatever 12pt is at 72dpi, in pixels, no matter what your real display res is". And don't suggest setting "large fonts" or worse setting the font res option to your actual display res - as the rest of the UI is all statically laid out, it chokes rather badly.
A 3D UI also makes doing interesting things with window management easier, or in fact practical.
IMO this is an opportunity for MS to do a lot right, and certainly isn't useless.
I'd like to disagree, but with the growing promenance of organized crime, highly profitable spam, and so on, I can't. I'm mildly surprised that one of the bigger organizations hasn't gone out and found someone who can do what they need and has few scruples about doing it when the money is right.
I can only assume that it's not worth doing - ie systems to crack are in such plentiful supply already that there's just no need to bother with real effort.
This is where Xen support for Mac OS X would rock. With a VT-enabled CPU (the coming Core Duos should be) it'd be possible to run Windows and Mac OS X side by side. Xen can also handle all the legacy BIOS emulation, etc.
Sounds nice, eh? Like you said, potentially just a hotkey to switch. It'd be harder to do if you wanted accelerated 3D etc but I doubt it's impossible. I'd be surprised if the TPM chip got in the way either.
For this to work really well it'd need support from Apple, and alas that pretty much means it won't happen thanks to the joys of Not Invented Here (TM).