What would the API for this "single persistent, networked, yet not completely shared-global" object concept look like? If nothing is typed, how - for example - does an image manipulation program know which objects represent data, which objects represent manipulations, and how to actually fit the two together? What if I come up with a new and useful way of manipulating data which doesn't fit into the existing API? If what used to be a large database in an optimised binary format is now a millions of individual objects inside collections, all untyped and limited to whatever metadata satisfies the lowest common denominator of code written for this object concept, how do I access and manipulate that data with anything approaching decent performance? How do I create an attractive UI for my application when it has no prior knowledge of what settings, properties or operations may be exposed by the components it uses, or even what components exist? If I invent a new or improved type of formatting for word processors, and there isn't already a property or set of properties in the object format which can express the data easily, do I just scrap the idea, or implement an object where the "real" data lives in an opaque blob in a non-standard property, defeating the whole point of generic objects?
Specialisation is a necessary evil when it comes to actually getting things done. Frameworks and APIs for implementing pluggable, re-usable components exist, but in the interests of being realistic, useful and performant, they are always specialised. Some examples:
* Gstreamer implements a wonderful pluggable framework for playing media, be it audio, video, streaming, stored, compressed, whatever. There are plug-ins for input types (file/network), codecs, multiplexing, de-multiplexing, filtering, rendering (e.g. displaying on screen/sending to sound card), and they can be plumbed together in any way that makes sense. To this end, plug-ins use a domain specific method for describing what they can consume, and what they can produce. It even manages to export UI information and accept user input, for things like DVD menus, though I have no idea how they managed to fit that in to the model. It can't be used to edit a Word document or interact with a web page, but web browsers can and do make use of it for displaying video data embedded in HTML5 documents. For performance, all operations beyond data loading/retrieval are performed on the local machine, in the address space of a single process, unless you specifically create a plug-in chain with the disk or the network as its output.
* D-Bus implements a simple, persistent message bus, where anything connected to the bus can send messages either to specific numbered entities, or to named interfaces. Anything which implements a given named interface can respond to these latter messages, and as long as the data is returned in the correct format for that interface, the sender will understand it. However, it's only as useful as the interfaces themselves; it can't magically connect anything to anything else, applications have to be written in advance to expect/implement specific, designed interfaces. I'm not sure how it would hold up performance-wise if you tried to connect up something like Gstreamer plug-ins over it - that would be a lot of messages, and an awful lot of data copying.
I would love for what you propose to be possible, but something tells me it's not grounded in reality.
GGP says: "Their architectural approach has been rather fucked up, too. Instead of using a true object-oriented language like C++, Objective-C, Python, Java, Smalltalk, or one of the many other OO languages out there at the time, they instead chose to create GObject. For those who don't know, GObject is a horrible kludge to add pseudo-object-oriented capabilities to C. It's a unholy mess of macros and other stupidity, and the result is completely shitty. Don't take my word for it. Go use it yourself! See how horrible of an experience it is compared to using a real UI toolkit like Qt, or Cocoa, or wxWidgets, or even MFC or Swing."
GP says: "As for the language, basing it on C was a wise choice. It's a far more portable language than C++ or Objective C, and *way* easier to bind other languages too. The GObject model works very well in other languages. Programming GTK+ in C++ is a joy (doesn't need moc either). GTK+ in Python is slick too, and actually manages to be fairly pythonic, unlike PyQt, which is really just C++ code in a python syntax."
You read this, and claim that these two people agree with each other on everything?
Hmmm... that would be quite ironic: making it possible to implement these applications in browsers with non-proprietary, cross-platform technologies, may be the very thing that drives vendors to ditch the lot and use proprietary, platform-specific solutions. Being cross-platform & proprietary is better than platform-specific & proprietary.
Will content providers be able to give out their material without DRM? Yes, in the sense that it's possible. Will they be *willing*? Probably not. Will we see all sorts of harebrained, browser-breaking hacks implemented to try and bring DRM to JavaScript and HTML video? Almost certainly.
Whilst it is true that.NET is not just a JIT compiler, in the same way that Java is not just a JIT compiler, the two do make similar guarantees about portability across processor architectures. Something LLVM-like would be a fantastic way to extend those guarantees to other compiled languages, but unfortunately, I can't see MS putting in the effort now that.NET exists. I don't like the way.NET and Java conflate being processor-agnostic with using specific programming languages & runtime libraries, but unfortunately, restricting developer choice seems to be the "in thing" these days - ostensibly for the purposes of consistency and consumer security.
If I wanted to make a serious go of Windows 8 development, learning.NET would seem an eminently sensible thing to do; however, as someone who prefers to write cross-platform (as in cross-OS) software whenever possible, I find the vendor lock-in disturbing.
Apparently they're talking both. I suspect many.NET apps would run on the ARM version just fine, if it wasn't for the fact that MS are, apparently, limiting said version to apps developed against the new Metro API.
(Yes, I know I pasted something very similar elsewhere on this article, but I really think the API incompatibility is much more egregious than x86 binary incompatibility.)
The stupid part is that it should never have gotten to this. Microsoft should, at the very least produced an architecture analogous to LLVM where devs could build and compile their apps just the once and it didn't matter if it was running on ARM or x86 or x86-64 or MIPS or anything else. When the app installed the system could compile native code from the LLVM bitcode and run that. It might not help with x86 emulation but it would offer a migration path, one far more compelling than what's on the table at the moment.
What, like.NET you mean? Nobody has officially come out and said that.NET binaries (which don't interface with native code) will work, but I suspect they will. The real problem here is not the lack of x86 emulation, or the lack of a CPU-agnostic runtime. The real problem is that MS aren't even providing an ARM version of the full Win32 API, just the API needed for Metro apps. I wouldn't be surprised if the desktop "app" just isn't there in the ARM version - only the Metro UI.
This is an interesting point, and one I wonder about myself... however, since anyone can be a notary, it may eventually prove infeasible to determine from the server end whether any given connection is from a notary (and hence should present the real certificate) or from a client (and hence should present a falsified certificate, allowing MITM). However, even if the attacker bites the bullet and just presents the falsified certificate to all comers, there are three time windows I can think of when a falsified certificate has a chance to become trusted: when a new notary is asked its opinion of a site for the first time (and hence has no prior record of what the certificate *should* be), when certificates get replaced following expiry/revocation/etc., and when new sites appear. In these last two cases, existing notaries are effectively tasked with determining whether a certificate nobody's seen before is valid, which sounds intractable to me.
I haven't made time to read the research this system is based on, but am very interested in how initial trust in brand-new certificates - whether for new sites, or replacement certs for existing sites - is supposed to be established.
For what it was, RISC OS truly rocked. I grew up with an Archimedes, and my first Windows PC ran 98, so I completely avoided DOS, 3.11, etc. - and from what I've seen, I still consider this to be "avoided", not "missed out on". Spatial file management and drag-to-save are two features of its GUI which I miss - although I'm not entirely sure drag-to-save would work quite as well with the sheer amount of files & folders people deal with now compared to back then. Maybe that in itself is a sign that file management & filesystem layouts have got too complex for their own good? Self-contained applications-in-folders was also made of win, though shared libraries (which are actually shared, not bundled with every app separately) do break the metaphor somewhat, and there are a lot of those on the average box these days. OS X may do something like this, but I'm damned if I'm ever going to buy anything from Apple.
I know there's ROX Desktop, but for some reason I've just never got round to trying it. I was one of the minority who was very pleased when spatial mode was added to Nautilus, and lament it no longer being the default.
I kinda miss the days when the OS was in ROM and you had to try very, very hard to "break" your computer in any way that couldn't be fixed by a simple power cycle. I understand the benefits of having the OS on writable media (upgrading by replacing ROM chips was, I would imagine, not an enjoyable experience - never had to do it personally), but I really do wish more was done to separate files comprising the OS from application data, user data and settings. I know better than to log in with admin privileges and delete the contents of C:\Windows, for example, but this is something that shouldn't be as easy as it is.
I also find it quite egregious that Windows doesn't ship with a programming environment. Visual Studio may have the Express editions these days, but there is nowhere near the same sense that a computer is a tool to be used as one sees fit. I distinctly remember that my first two impressions of Windows 98 were "where's BASIC gone?" and "wow, this 3D graphics stuff is awesome"*. I miss BBC BASIC on the Archimedes to the extent that I still bind "open terminal" in GNOME to F12.
As for TFA, I agree with all the commenters saying it sounds like a bunch of old farts moaning because they can't/won't learn to use modern tools. Everything they're complaining about is either gone for a reason or still exists; meanwhile, mentions of things which actually *are gone* and *were good* are completely absent.
* It came with a copy of Rage Software's "Incoming", and I'd never seen anything like it before - the only thing I feel I "missed out" on from the DOS days was playing the original releases of DOOM and Quake, back when they were actually new.
I think you have missed the point here. Windows on ARM will not run legacy software, but Intel don't manufacture ARM chips any more. If there is going to be a version of Windows 8 which *does* run on Intel chips, it will target the x86 architecture, which brings a lot of baggage and backwards compatibility headaches of its own. Saying that Windows 8 won't run software for earlier versions of Windows does not magically mean that Intel will stop pushing x86 as their primary architecture, or allow them to cut the baggage from the instruction set. An x86 processor has to be compatible with the x86 instruction set, end of story.
If Intel do decide to start pushing something else in preference to x86, like they tried (and largely failed) with Itanium, then it will be big news (as Itanium was at the time). This new architecture would also need a version of Windows compiled specially for it, and would not automatically be in a better position to run legacy x86 software than Windows on ARM. Instead, what I expect to happen is for Intel to keep pushing full-speed-ahead with x86, claiming that the ability to run legacy applications on the x86 version of Windows 8 is a compelling reason not to invest in the ARM version.
tl;dr: Microsoft dropping backwards compatibility from Windows 8 != Intel dropping backwards compatibility from x86.
I disagree with the idea that the human brain tackles the task of throwing balls through hoops by mathematically analysing the problem. There is no numerical estimation going on.
What the brain needs to know is how to coordinate the motor system so as to throw the ball roughly where it needs to go, which it learns through trial and error. The first few times one throws a ball (having never thrown one before), one will miss; success rates will improve with practice, but will never reach 100% even for duplicate scenarios. With enough practice - both in terms of quantity, and variety, of scenario - patterns will begin to emerge which can be exploited to generalise the necessary motions, adjusting them to previously unencountered scenarios, but I contend that there are still no numerical methods involved.
People forget all too easily that the brain is connected to the body, is specialised to the task of controlling that body, and gets an awful lot of rapid, rich feedback from it. I suspect this has more to do with the brain's efficacy than most people realise.
In version 3, sort of, but it's to do with people contributing code based on patents owned by them. Basically, if I own a software patent and contribute some code falling under the patent to a GPLed program, I grant the licensees of that program "a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version".
The only mention of relicensing is that if you start off with something licensed under "GPL plus other restrictions", but which permits relicensing (vanilla GPL 3 does not, AFAICT), and then create a derivative work by adding material from some other GPL 3 work, the end result must not include the first work's additional restrictions in its license (since that would constitute relicensing material from the second work, which may not be permitted).
Nexuiz appears to be licensed under GPL 2, not 3, which contains none of the wording I'm referring to above.
It's not unheard of for projects to require that contributors assign copyright to some central entity as a pre-condition for contributing. Alientrap are probably wishing they had done this (it would have to have been there from day one).
Essentially, they tried that and it didn't work. Hale doesn't have copyright on all the code in current GPL Nexuiz, and wasn't able to obtain it from all contributors. IANAL, but as I understand it the rule of thumb is that you can't re-license something if you aren't the copyright holder.
If it already has replacement art and audio, and now it appears will have replacement code as well, at what point does it stop being the same game? Nexuiz may be popular by FOSS game standards, but realistically I don't think it's popular enough that the branding will give the console releases any significant head start. If anything, now that their original dual-licensing plans have been foiled (regardless of whether that is for better or worse), IMHO they would be better off distancing themselves from the original and the surrounding controversy.
Give the domain back, come up with a new name, move on, end of story.
I think this fairly conclusively proves that, when fully implemented, HTML 5 can do everything Flash can do - at least, all the useful bits. Yes, I know, this only supports old Flash versions and doesn't do audio or video, but we already know HTML 5 can do audio and video - what people never quite believed was that the various parts of HTML 5 could be combined to provide the same presentation quality and interactivity as Flash. (At least, that's the impression I always had.)
However, instead of translating Flash to HTML 5 (which is a very neat trick, I have to admit), how about producing rich authoring tools which output directly to HTML 5? Otherwise, people will just continue to create Flash, because it will continue to be easier than writing directly for the alternative.
Compare & contrast using Glade with writing GtkBuilder XML files by hand. I've tweaked Glade's output by hand before now, but I wouldn't like to start from scratch. Not quite an equivalent example, since the end result in both cases is interpreted in the same way at run-time, but you get the idea.
My apologies, this wasn't meant to sound like a personal attack.:)
My dislike of Qt is real, but I shouldn't have got so carried away focusing on that specifically. The wider, more subtle point I was making is that in the open source world, people are used to having more freedom and alternatives than in the proprietary world. Having a single, all-encompassing, well-maintained, well-marketed solution definitely sounds attractive, but you'd never get everyone to agree on what it should look like - everyone would have different ideas on which components should be packaged into that solution, with some people no doubt thinking that certain parts of it should be written from scratch.
In reality, if I was writing a 3D engine, I probably wouldn't use GTK *or* Qt. Assuming we're talking an engine for traditional full-screen 3D games, I'd probably use some kind of toolkit capable of rendering its widgets using OpenGL, with SDL for input handling.
I'm sorry, but... Qt? Yuck. Give me something with a plain C API and optional C++ wrapper, not a native C++ API. Give me something that doesn't have its own "make" variant to make building "easier". Give me something that doesn't rely on macros and a custom code pre-processor to implement signals & slots, when it's been fairly conclusively proven that these features can be implemented using plain old C/C++.
Please, if you're going to do something like this, don't take a reasonably well-written plain-old-C API like OpenGL and sully it by association with something which is, in comparison, broken by design.
For something which underpins so many open-source applications, and touts cross-platform compatibility as its major feature, Qt seems to make so many departures from library-writing best practices that I often wonder why it has been adopted as widely as it has. Thankfully I am currently succeeding in keeping Qt (and KDE) off my Linux installs - I run one closed-source Qt application for work purposes, and ironically, running the Windows version in WINE works better and provides more features than running the Linux-native version.
Those are reasonable examples, but I don't see common applications involving SMS datestamps being sent directly to 7-segment displays. Nor do I really class storage of arcade game high scores as a "file format" for the purposes of this discussion - they're only ever intended to be loaded back up by the same software, running on the same hardware. This is even more closed than, say, Word docs (pre-OOXML); at least putting a Word doc on disc and transferring it to a different machine falls under intended usage.
I'm thinking more of data interchange standards, be they open or proprietary.
Given the EE angle, I can now see how this stuff might have crept in, but am still not convinced it has any business being part of modern standards. As I said, I can see how it makes certain operations easier - so fine, store it in RAM and use it for those operations, but don't put it on disc/on the 'net if there's any chance someone else's software will have to interpret it at the other end.
This is the kind of thing I'm talking about. To me it seems more sensible to just store cents and use all the available number range, than it does to limit yourself to BCD and open the door to misinterpretation of stored values.
But what moron would use BCD as a format for integer storage/transmission? It might be easier to perform certain operations with, but as a storage format it's just unnecessarily wasteful. Given that plain old binary can store greater ranges with the same number of bytes, I'm struggling to think of any reason why any protocol or file format needing a fixed width integer field should use BCD instead.
If you can present a modern valid use case, please do; but my current impression is that BCD smells of obsolescence. (Needing to work with existing file formats/protocols doesn't count; whoever designed the format/protocol in the first place had better have a good reason for doing it that way.)
It would be kind of awesome if files were accessed the same way as memory areas though. Kind of like if everything was transparently mmap-ed, but with the ability to grow/shrink the area, and with the option to have changes reflected immediately on the underlying medium.
file *foo = new file("/dev/pcm");
foo->append("Hello world1");
foo[11] = '!';
save foo;
(sorry for replying to my own post, forgive me mods!)
The speed of PCM would need to closely match - or exceed - the speed of DRAM for people to adopt it as a replacement, so I doubt the model would quite be one of non-volatile RAM. I imagine it would be more like having a ridiculously fast SSD.
Given the propensity of programs to corrupt and/or leak memory, I'm not sure I'd want my system memory to be non-volatile. The dividing line between system memory and mass storage allows for robustness against errors which, without the ability to reboot, wipe the slate clean and load up the last saved data, might end up being catastrophic. It'd be nice if no program ever had such errors, but this is reality.;)
If nothing else, programs will always need the ability to serialise data into platform-agnostic formats, unless you expect the world to standardise on one platform or stop sharing data.
Slashdot Mirror
All this, and yet you can't spell Edinburgh, despite feeling the need to name-drop it.
At least, I assume that's where you're referring to, since I can't find any information about a place called "Endbraugh".
What would the API for this "single persistent, networked, yet not completely shared-global" object concept look like? If nothing is typed, how - for example - does an image manipulation program know which objects represent data, which objects represent manipulations, and how to actually fit the two together? What if I come up with a new and useful way of manipulating data which doesn't fit into the existing API? If what used to be a large database in an optimised binary format is now a millions of individual objects inside collections, all untyped and limited to whatever metadata satisfies the lowest common denominator of code written for this object concept, how do I access and manipulate that data with anything approaching decent performance? How do I create an attractive UI for my application when it has no prior knowledge of what settings, properties or operations may be exposed by the components it uses, or even what components exist? If I invent a new or improved type of formatting for word processors, and there isn't already a property or set of properties in the object format which can express the data easily, do I just scrap the idea, or implement an object where the "real" data lives in an opaque blob in a non-standard property, defeating the whole point of generic objects?
Specialisation is a necessary evil when it comes to actually getting things done. Frameworks and APIs for implementing pluggable, re-usable components exist, but in the interests of being realistic, useful and performant, they are always specialised. Some examples:
* Gstreamer implements a wonderful pluggable framework for playing media, be it audio, video, streaming, stored, compressed, whatever. There are plug-ins for input types (file/network), codecs, multiplexing, de-multiplexing, filtering, rendering (e.g. displaying on screen/sending to sound card), and they can be plumbed together in any way that makes sense. To this end, plug-ins use a domain specific method for describing what they can consume, and what they can produce. It even manages to export UI information and accept user input, for things like DVD menus, though I have no idea how they managed to fit that in to the model. It can't be used to edit a Word document or interact with a web page, but web browsers can and do make use of it for displaying video data embedded in HTML5 documents. For performance, all operations beyond data loading/retrieval are performed on the local machine, in the address space of a single process, unless you specifically create a plug-in chain with the disk or the network as its output.
* D-Bus implements a simple, persistent message bus, where anything connected to the bus can send messages either to specific numbered entities, or to named interfaces. Anything which implements a given named interface can respond to these latter messages, and as long as the data is returned in the correct format for that interface, the sender will understand it. However, it's only as useful as the interfaces themselves; it can't magically connect anything to anything else, applications have to be written in advance to expect/implement specific, designed interfaces. I'm not sure how it would hold up performance-wise if you tried to connect up something like Gstreamer plug-ins over it - that would be a lot of messages, and an awful lot of data copying.
I would love for what you propose to be possible, but something tells me it's not grounded in reality.
WTF? Did you read the same two posts that I did?
GGP says: "Their architectural approach has been rather fucked up, too. Instead of using a true object-oriented language like C++, Objective-C, Python, Java, Smalltalk, or one of the many other OO languages out there at the time, they instead chose to create GObject. For those who don't know, GObject is a horrible kludge to add pseudo-object-oriented capabilities to C. It's a unholy mess of macros and other stupidity, and the result is completely shitty. Don't take my word for it. Go use it yourself! See how horrible of an experience it is compared to using a real UI toolkit like Qt, or Cocoa, or wxWidgets, or even MFC or Swing."
GP says: "As for the language, basing it on C was a wise choice. It's a far more portable language than C++ or Objective C, and *way* easier to bind other languages too. The GObject model works very well in other languages. Programming GTK+ in C++ is a joy (doesn't need moc either). GTK+ in Python is slick too, and actually manages to be fairly pythonic, unlike PyQt, which is really just C++ code in a python syntax."
You read this, and claim that these two people agree with each other on everything?
Hmmm... that would be quite ironic: making it possible to implement these applications in browsers with non-proprietary, cross-platform technologies, may be the very thing that drives vendors to ditch the lot and use proprietary, platform-specific solutions. Being cross-platform & proprietary is better than platform-specific & proprietary.
Will content providers be able to give out their material without DRM? Yes, in the sense that it's possible. Will they be *willing*? Probably not. Will we see all sorts of harebrained, browser-breaking hacks implemented to try and bring DRM to JavaScript and HTML video? Almost certainly.
Whilst it is true that .NET is not just a JIT compiler, in the same way that Java is not just a JIT compiler, the two do make similar guarantees about portability across processor architectures. Something LLVM-like would be a fantastic way to extend those guarantees to other compiled languages, but unfortunately, I can't see MS putting in the effort now that .NET exists. I don't like the way .NET and Java conflate being processor-agnostic with using specific programming languages & runtime libraries, but unfortunately, restricting developer choice seems to be the "in thing" these days - ostensibly for the purposes of consistency and consumer security.
If I wanted to make a serious go of Windows 8 development, learning .NET would seem an eminently sensible thing to do; however, as someone who prefers to write cross-platform (as in cross-OS) software whenever possible, I find the vendor lock-in disturbing.
Apparently they're talking both. I suspect many .NET apps would run on the ARM version just fine, if it wasn't for the fact that MS are, apparently, limiting said version to apps developed against the new Metro API.
Source: http://www.anandtech.com/show/4771/microsoft-build-windows-8-pre-beta-preview/5
(Yes, I know I pasted something very similar elsewhere on this article, but I really think the API incompatibility is much more egregious than x86 binary incompatibility.)
The stupid part is that it should never have gotten to this. Microsoft should, at the very least produced an architecture analogous to LLVM where devs could build and compile their apps just the once and it didn't matter if it was running on ARM or x86 or x86-64 or MIPS or anything else. When the app installed the system could compile native code from the LLVM bitcode and run that. It might not help with x86 emulation but it would offer a migration path, one far more compelling than what's on the table at the moment.
What, like .NET you mean? Nobody has officially come out and said that .NET binaries (which don't interface with native code) will work, but I suspect they will. The real problem here is not the lack of x86 emulation, or the lack of a CPU-agnostic runtime. The real problem is that MS aren't even providing an ARM version of the full Win32 API, just the API needed for Metro apps. I wouldn't be surprised if the desktop "app" just isn't there in the ARM version - only the Metro UI.
Source: http://www.anandtech.com/show/4771/microsoft-build-windows-8-pre-beta-preview/5
This is an interesting point, and one I wonder about myself... however, since anyone can be a notary, it may eventually prove infeasible to determine from the server end whether any given connection is from a notary (and hence should present the real certificate) or from a client (and hence should present a falsified certificate, allowing MITM). However, even if the attacker bites the bullet and just presents the falsified certificate to all comers, there are three time windows I can think of when a falsified certificate has a chance to become trusted: when a new notary is asked its opinion of a site for the first time (and hence has no prior record of what the certificate *should* be), when certificates get replaced following expiry/revocation/etc., and when new sites appear. In these last two cases, existing notaries are effectively tasked with determining whether a certificate nobody's seen before is valid, which sounds intractable to me.
I haven't made time to read the research this system is based on, but am very interested in how initial trust in brand-new certificates - whether for new sites, or replacement certs for existing sites - is supposed to be established.
For what it was, RISC OS truly rocked. I grew up with an Archimedes, and my first Windows PC ran 98, so I completely avoided DOS, 3.11, etc. - and from what I've seen, I still consider this to be "avoided", not "missed out on". Spatial file management and drag-to-save are two features of its GUI which I miss - although I'm not entirely sure drag-to-save would work quite as well with the sheer amount of files & folders people deal with now compared to back then. Maybe that in itself is a sign that file management & filesystem layouts have got too complex for their own good? Self-contained applications-in-folders was also made of win, though shared libraries (which are actually shared, not bundled with every app separately) do break the metaphor somewhat, and there are a lot of those on the average box these days. OS X may do something like this, but I'm damned if I'm ever going to buy anything from Apple.
I know there's ROX Desktop, but for some reason I've just never got round to trying it. I was one of the minority who was very pleased when spatial mode was added to Nautilus, and lament it no longer being the default.
I kinda miss the days when the OS was in ROM and you had to try very, very hard to "break" your computer in any way that couldn't be fixed by a simple power cycle. I understand the benefits of having the OS on writable media (upgrading by replacing ROM chips was, I would imagine, not an enjoyable experience - never had to do it personally), but I really do wish more was done to separate files comprising the OS from application data, user data and settings. I know better than to log in with admin privileges and delete the contents of C:\Windows, for example, but this is something that shouldn't be as easy as it is.
I also find it quite egregious that Windows doesn't ship with a programming environment. Visual Studio may have the Express editions these days, but there is nowhere near the same sense that a computer is a tool to be used as one sees fit. I distinctly remember that my first two impressions of Windows 98 were "where's BASIC gone?" and "wow, this 3D graphics stuff is awesome"*. I miss BBC BASIC on the Archimedes to the extent that I still bind "open terminal" in GNOME to F12.
As for TFA, I agree with all the commenters saying it sounds like a bunch of old farts moaning because they can't/won't learn to use modern tools. Everything they're complaining about is either gone for a reason or still exists; meanwhile, mentions of things which actually *are gone* and *were good* are completely absent.
* It came with a copy of Rage Software's "Incoming", and I'd never seen anything like it before - the only thing I feel I "missed out" on from the DOS days was playing the original releases of DOOM and Quake, back when they were actually new.
I think you have missed the point here. Windows on ARM will not run legacy software, but Intel don't manufacture ARM chips any more. If there is going to be a version of Windows 8 which *does* run on Intel chips, it will target the x86 architecture, which brings a lot of baggage and backwards compatibility headaches of its own. Saying that Windows 8 won't run software for earlier versions of Windows does not magically mean that Intel will stop pushing x86 as their primary architecture, or allow them to cut the baggage from the instruction set. An x86 processor has to be compatible with the x86 instruction set, end of story.
If Intel do decide to start pushing something else in preference to x86, like they tried (and largely failed) with Itanium, then it will be big news (as Itanium was at the time). This new architecture would also need a version of Windows compiled specially for it, and would not automatically be in a better position to run legacy x86 software than Windows on ARM. Instead, what I expect to happen is for Intel to keep pushing full-speed-ahead with x86, claiming that the ability to run legacy applications on the x86 version of Windows 8 is a compelling reason not to invest in the ARM version.
tl;dr: Microsoft dropping backwards compatibility from Windows 8 != Intel dropping backwards compatibility from x86.
I disagree with the idea that the human brain tackles the task of throwing balls through hoops by mathematically analysing the problem. There is no numerical estimation going on.
What the brain needs to know is how to coordinate the motor system so as to throw the ball roughly where it needs to go, which it learns through trial and error. The first few times one throws a ball (having never thrown one before), one will miss; success rates will improve with practice, but will never reach 100% even for duplicate scenarios. With enough practice - both in terms of quantity, and variety, of scenario - patterns will begin to emerge which can be exploited to generalise the necessary motions, adjusting them to previously unencountered scenarios, but I contend that there are still no numerical methods involved.
People forget all too easily that the brain is connected to the body, is specialised to the task of controlling that body, and gets an awful lot of rapid, rich feedback from it. I suspect this has more to do with the brain's efficacy than most people realise.
No, that's how Chuck Norris flies.
Given recent breakthroughs in AI technology, we can infer with 95% certainty that Chuck Norris is in fact a helicopter.
In version 3, sort of, but it's to do with people contributing code based on patents owned by them. Basically, if I own a software patent and contribute some code falling under the patent to a GPLed program, I grant the licensees of that program "a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version".
The only mention of relicensing is that if you start off with something licensed under "GPL plus other restrictions", but which permits relicensing (vanilla GPL 3 does not, AFAICT), and then create a derivative work by adding material from some other GPL 3 work, the end result must not include the first work's additional restrictions in its license (since that would constitute relicensing material from the second work, which may not be permitted).
Nexuiz appears to be licensed under GPL 2, not 3, which contains none of the wording I'm referring to above.
It's not unheard of for projects to require that contributors assign copyright to some central entity as a pre-condition for contributing. Alientrap are probably wishing they had done this (it would have to have been there from day one).
Essentially, they tried that and it didn't work. Hale doesn't have copyright on all the code in current GPL Nexuiz, and wasn't able to obtain it from all contributors. IANAL, but as I understand it the rule of thumb is that you can't re-license something if you aren't the copyright holder.
If it already has replacement art and audio, and now it appears will have replacement code as well, at what point does it stop being the same game? Nexuiz may be popular by FOSS game standards, but realistically I don't think it's popular enough that the branding will give the console releases any significant head start. If anything, now that their original dual-licensing plans have been foiled (regardless of whether that is for better or worse), IMHO they would be better off distancing themselves from the original and the surrounding controversy.
Give the domain back, come up with a new name, move on, end of story.
I think this fairly conclusively proves that, when fully implemented, HTML 5 can do everything Flash can do - at least, all the useful bits. Yes, I know, this only supports old Flash versions and doesn't do audio or video, but we already know HTML 5 can do audio and video - what people never quite believed was that the various parts of HTML 5 could be combined to provide the same presentation quality and interactivity as Flash. (At least, that's the impression I always had.)
However, instead of translating Flash to HTML 5 (which is a very neat trick, I have to admit), how about producing rich authoring tools which output directly to HTML 5? Otherwise, people will just continue to create Flash, because it will continue to be easier than writing directly for the alternative.
Compare & contrast using Glade with writing GtkBuilder XML files by hand. I've tweaked Glade's output by hand before now, but I wouldn't like to start from scratch. Not quite an equivalent example, since the end result in both cases is interpreted in the same way at run-time, but you get the idea.
My apologies, this wasn't meant to sound like a personal attack. :)
My dislike of Qt is real, but I shouldn't have got so carried away focusing on that specifically. The wider, more subtle point I was making is that in the open source world, people are used to having more freedom and alternatives than in the proprietary world. Having a single, all-encompassing, well-maintained, well-marketed solution definitely sounds attractive, but you'd never get everyone to agree on what it should look like - everyone would have different ideas on which components should be packaged into that solution, with some people no doubt thinking that certain parts of it should be written from scratch.
In reality, if I was writing a 3D engine, I probably wouldn't use GTK *or* Qt. Assuming we're talking an engine for traditional full-screen 3D games, I'd probably use some kind of toolkit capable of rendering its widgets using OpenGL, with SDL for input handling.
I'm sorry, but... Qt? Yuck. Give me something with a plain C API and optional C++ wrapper, not a native C++ API. Give me something that doesn't have its own "make" variant to make building "easier". Give me something that doesn't rely on macros and a custom code pre-processor to implement signals & slots, when it's been fairly conclusively proven that these features can be implemented using plain old C/C++.
Please, if you're going to do something like this, don't take a reasonably well-written plain-old-C API like OpenGL and sully it by association with something which is, in comparison, broken by design.
For something which underpins so many open-source applications, and touts cross-platform compatibility as its major feature, Qt seems to make so many departures from library-writing best practices that I often wonder why it has been adopted as widely as it has. Thankfully I am currently succeeding in keeping Qt (and KDE) off my Linux installs - I run one closed-source Qt application for work purposes, and ironically, running the Windows version in WINE works better and provides more features than running the Linux-native version.
Those are reasonable examples, but I don't see common applications involving SMS datestamps being sent directly to 7-segment displays. Nor do I really class storage of arcade game high scores as a "file format" for the purposes of this discussion - they're only ever intended to be loaded back up by the same software, running on the same hardware. This is even more closed than, say, Word docs (pre-OOXML); at least putting a Word doc on disc and transferring it to a different machine falls under intended usage.
I'm thinking more of data interchange standards, be they open or proprietary.
Given the EE angle, I can now see how this stuff might have crept in, but am still not convinced it has any business being part of modern standards. As I said, I can see how it makes certain operations easier - so fine, store it in RAM and use it for those operations, but don't put it on disc/on the 'net if there's any chance someone else's software will have to interpret it at the other end.
This is the kind of thing I'm talking about. To me it seems more sensible to just store cents and use all the available number range, than it does to limit yourself to BCD and open the door to misinterpretation of stored values.
But what moron would use BCD as a format for integer storage/transmission? It might be easier to perform certain operations with, but as a storage format it's just unnecessarily wasteful. Given that plain old binary can store greater ranges with the same number of bytes, I'm struggling to think of any reason why any protocol or file format needing a fixed width integer field should use BCD instead.
If you can present a modern valid use case, please do; but my current impression is that BCD smells of obsolescence. (Needing to work with existing file formats/protocols doesn't count; whoever designed the format/protocol in the first place had better have a good reason for doing it that way.)
The only good code is my code.
(No, that's not the kind of thinking that got is into this mess; clearly everyone else's code is what did that!)
It would be kind of awesome if files were accessed the same way as memory areas though. Kind of like if everything was transparently mmap-ed, but with the ability to grow/shrink the area, and with the option to have changes reflected immediately on the underlying medium.
file *foo = new file("/dev/pcm");
foo->append("Hello world1");
foo[11] = '!';
save foo;
(sorry for replying to my own post, forgive me mods!)
The speed of PCM would need to closely match - or exceed - the speed of DRAM for people to adopt it as a replacement, so I doubt the model would quite be one of non-volatile RAM. I imagine it would be more like having a ridiculously fast SSD.
Given the propensity of programs to corrupt and/or leak memory, I'm not sure I'd want my system memory to be non-volatile. The dividing line between system memory and mass storage allows for robustness against errors which, without the ability to reboot, wipe the slate clean and load up the last saved data, might end up being catastrophic. It'd be nice if no program ever had such errors, but this is reality. ;)
If nothing else, programs will always need the ability to serialise data into platform-agnostic formats, unless you expect the world to standardise on one platform or stop sharing data.