Every man and their dog seems to be mentioning Eclipse, and I've seen a couple of mentions of KDevelop, but nobody has mentioned Anjuta. I've tried Eclipse briefly, and found it highly confusing - I must admit I gave up fairly quickly. I haven't tried KDevelop, and don't particularly want to, because I've never liked KDE or Qt and don't want the libraries taking up valuable space and time (yes, I use Gentoo - go on, laugh if you like:P ) on my machine.
Now, Anjuta claims to be written in - and for - GTK/GNOME, but in reality it's just a GTK front-end to the Autotools and GDB which happens to come with a collection of GTK-oriented project templates. I must admit to not knowing what Eclipse and KDevelop generate in terms of a build system for projects, but what I like most about Anjuta is that it uses the Autotools completely and utterly: adding sources and targets (programs/libraries) simply adds entries into the relevant Makefile.am files, adding external library dependencies (it can automatically find and add support for anything on the system which uses pkg-config) adds to configure.ac, and those files are the *only* place that information is stored. When you load an "Anjuta project" up, it re-creates the project hierarchy by parsing those files back in; it doesn't store any metadata you'd be particularly bothered about losing, which means that if the person sat next to me wants to, they can work on the exact same project using Vim and a terminal. After all, building the project is no more difficult than any other Autotools package.:)
Its GDB integration is good, the editors - you can choose either a Scintilla-based one or a GtkSourceView-based one - are capable, and if you *do* happen to want to develop a GTK/GNOME app, things like DevHelp integration just help make life easier and make the whole thing feel that little bit more "professional". My only real complaint is that it can't automatically write configure scripts to look for non pkg-config libraries, but I know how difficult that can be for humans at the best of times.;)
In the end, my housemate had to give me his SSN, date of birth, employee data, and everything needed to log into the website from my computer. I saved a local copy and emailed it to him when I was done printing it.
I'm not excusing the complete and utter stupidity of Vista's behaviour, but:
It's a PDF, you say. Have Microsoft "embraced and extended" HTTP to include privacy flags, or is the flag part of the PDF specs, and hence Adobe's wonderful idea?
Couldn't your housemate have just installed a different browser? (Again, not excusing Vista here as you shouldn't have to do this, but it's not news that Internet Explorer is crap.)
You say this person is your housemate. Couldn't you just let them use your computer for five minutes (then delete saved form data, cache, and whatever else you would deem necessary) instead of giving you their personal info to perform the download on their behalf?
The work being done here is, essentially, taking existing 3D game content and rendering it using a raytracer. One of the benefits of raytracing is that it can render real curved surfaces, including NURBS and volumetric surfaces: without taking advantage of this aspect of the technology, would we really see much visual benefit? Hard-edged shadows are already possible with rasterizers, and a lot of the potential for visual quality in refractive surfaces (glass) would be lost without real curves: it wouldn't necessarily look much better than the existing approximations. It might just be that what we're looking at here is effectively "programmer art", but hard-edged shadows, flat textured surfaces and overly-shiny metallic objects can look worse than current rasterized graphics. Who, when creating a modern computer game, thinks "I wish I could render a perfect sphere here" or "A reflective torus would look brilliant in the centre of this room"? Mathematically and algorithmically pleasing or not, plastic-y graphics won't cut it in the real world.
We won't be getting away from polygons any time soon because realism comes less from simulating perfect surfaces, and more from *imperfect* surfaces. Note how much work is being done to increase the level of imperfections in our graphics: higher detail textures, bump mapping, increased polygon counts specifically aimed at removing the need for large flat areas.
3D modellers don't create mathematically perfect shapes. Since we won't be going away from polygons any time soon, and the visual benefits of raytracing have largely been simulated well enough already, it all comes down to whether or not the *performance* of raytracing will eventually outstrip rasterizers, since the *quality* issue is almost a moot point. Now, show me realtime path-tracing or global illumination and I'll be more convinced.
Not that I don't like raytracers. I've written one, and spent my final year at uni optimising it (just for a masters, not for a doctorate, so it wasn't exactly ground-breaking work). Just not convinced they're the right tool for the job, seeing as in their purest form, they've already been supplanted.
1 ray per pixel? Not true if you want light sources other than "ambient" (shadows or otherwise) or reflections. One ray per pixel to discover which object is visible at that point, then one ray per lightsource to find out whether or not it is casting light on the point of intersection, plus at least one more ray if the surface is reflective. If you want to render shadows in reflections, and nested reflections, the algorithm becomes recursive. Also, for each ray, you need to calculate which of the "thousands to millions" of triangles it intersects with - the algorithm being effectively both forking and recursive if you want translucency (shadow rays, reflective rays etc. need to be cast from the surface of the translucent object, *and* whatever object(s) are visible behind it).
Put simply: raytracing doesn't intrinsically scale with number of objects better than traditional rasterizers. With naive implementations of intersection tests, it can scale *worse*.
Disclaimer: I haven't actually tried this, and so may be talking utter BS. However...
Surely the shell will expand 'rm *' such that the listing will include anything in the current directory, regardless of name? That should, in this case, get a literal '*' inserted into the arguments that get passed to 'rm'. Since it's reasonable to assume that the shell won't try to expand arguments recursively, and that 'rm' neither has its own expansion routines (duplicating functionality from the shell) nor is itself a shell script, the file '*' will be deleted just fine.
Alternatively, couldn't you just run 'rm \*'?
Not quite sure what's so "interesting" about this one.
I once typed 'rm -rf/etc' on my box at work instead of 'rm -rf etc'. I was attempting to clean out part of either a virtual machine or chroot environment (I forget which), but unfortunately ended up running the command on the host itself.
Working for a company whose product is at its core a specialised Linux distro leads to all sorts of confusing moments - it's not uncommon for me to have my machine running two or three instances of QEMU running our products (with at least one more running Windows on the same virtual network), two or three terminals open on the host (which may or may not be running an SSH session to one of the virtual machines), an SSHFS mount point or two on the host to the guest's file systems, and a copy of our build environment, a fully-fledged chroot environment with its own toolchain (which is also a Subversion working copy, but can only be usefully used as such whilst not chrooted).
The best part is that I was able to stop the command half-way through and actually recover the system without a reinstall - in fact, I'm still using the same install of the same OS to this day (this was about a year ago now). This was/is Gentoo (as developers we get free reign over our own machines, the only requirement being that our choice of OS can build - or be persuaded to build without too much hassle - a local copy of our build environment); I had to recreate a few important things such as/etc/make.conf and/etc/profile, but since I basically still had a working build environment and was logged in as root when having run The Command, I was able to get the rest back eventually (as long as I didn't log out, and as long as I didn't mind losing the rest of that working day compiling stuff).
Re:Are we really making it better for us, or worse
on
Finding New Code
·
· Score: 1
There are laws to protect the code.
There are laws there to protect a lot of things. To give a somewhat extreme example, there are laws that say it's the driver's fault if I get run over whilst cycling (in some countries/circumstances) - but those laws won't magically rush in and pull me out at the last second, or reinforce my cycle helmet such that it can withstand speeding lorries, or anything of the sort. You can't benefit from compensation if you're dead.
My point is this: given a compiled (i.e. non-human-readable) executable file, can you tell whether or not the source code from which it was compiled violates any licenses? Not realistically, no. Being illegal doesn't stop a lot of people from doing a lot of things, or we'd probably have achieved world peace already. Laws are also not automatically enforceable by merit of existence.
That said, I don't think this search engine will encourage anyone to commit licensing violations who isn't already perfectly happy doing so (or ignorant of what they're doing). I just don't think legality has anything to do with it, unfortunately.
And won't somebody snapping up my or my blog's domain name be able to steal my
identity as well now? That's decidedly awful (far worse than losing your email
address) if your bank or credit card provider is using OpenID.
They may be able to "steal" an old OpenID URL in the sense that they are now able to identify themselves as owning it, where previously you identified yourself as owning it. However as I said in my original post, they do NOT automatically steal any more personal information you might have associated with your OpenID, such as financial details. This would only happen if your OpenID provider was hacked into, or if you were running the provider yourself, and they inherited the whole server - disk contents and all - rather than just the domain name.
If you want to keep your OpenID URL constant, then yes, you do need to maintain ownership of that URL, regardless of whether you're using delegation. However if you are using delegation, then you can lose your entire web hosting account and simply start using the non-delegated URL directly without having to re-enter any other information you had stored in your OpenID account.
I see two scenarios:
In the blogging/social networking world, losing your URL could have quite a large impact, because that URL is in a sense your name, your mark, your signature. People see it and assume they know who they're dealing with.
In the web services world, losing your URL might not really matter at all, if you were using delegation. This is because the "URL-as-signature" association is not visible in the same way it would be on a social site; instead, OpenID is simply being used as a way not to re-enter personal details each time you use a new service, and these details have not been lost (you have lost the URL, not the underlying OpenID account). You might lose trivial settings data for individual sites, but in my opinion, OpenID consumers should never key any sensitive data purely against a URL.
There is nothing to stop an OpenID-enabled site from taking simple details - such as name, email address, age - from your OpenID profile automatically, and allowing you access to features which simply require an identity (e.g. comment posting), but then optionally require some site-specific secret on top of that in order to use features which require trust (e.g. financial transactions). True, this goes against the holy grail of single sign-on, but it is one way to add a trust layer to a system which, due to its decentralised nature, can never guarantee that old identities do not get re-assigned. There may be other, more elegant solutions, but it is important to notice the need for such a layer.
Continuing on the theme of e-commerce, is there a need for a trust layer in the event that OpenID consumers never cache sensitive data? Someone could steal your OpenID URL and sign in to a shopping site you've used, but unless they have already stolen your credit card number by some other means, their OpenID provider will not be able to give that information out, because it won't know it (assuming your OpenID provider has remained secure).
If www.a.com goes away, his account on www.b.com is still perfectly usable; he can either start using its OpenID URL directly, or get a new website and delegate that one to it. True, he can no longer identify himself as www.a.com, but the system can't be so decentralised that even the ID you present is not constant - wouldn't it kind of defeat the point of an identification framework if everybody's ID was always changing? If Johnny owns and operates www.a.com and it goes away for a reason such as non-payment, he has nobody else to blame; other than that, it's just a case of picking reliable providers. Have you never had to change your email address, or played around with cheap webhosting only to abandon the account later (possibly for reasons outside your control)? These two problems are not specific to OpenID, I would argue.
A more interesting one, which does concern me, is what might happen if Johnny loses his domain name and it gets snapped up by someone else, who then creates an OpenID account and posts on all Johnny's old haunts pretending to be him. How do you protect against that? But then again, the system is more about identification than authentication*. If, for example, someone created an extension to OpenID for the storage of payment details - not that I personally think this would be an appropriate usage of the system - then losing his domain name might mean he has to start identifying himself via a different URL, but the domain's next owner hasn't magically gained access to his credit card number (which is still locked away by his OpenID provider, and as secure as their site is).
Anyone considering forming a serious attachment to an OpenID URL needs to pick one they are confident they can hold on to, delegated or otherwise. My personal usage of the framework has been as a rudimentary anti-spam system (requring *any* form of authentication is a barrier of sorts to automated posting, especially for low-profile, personal sites), as a way to identify myself when leaving comments on friend's LJ blogs, and as a way for them to identify themselves on my own blog without the hassle of signing up for it specifically.
* There is a difference between the two; authentication implies trust. Example: if you imported a GPG key bearing a friend's name from a public keyserver, without asking them in person whether this key does actually belong to them, is a message signed by that key guaranteed to actually have been written by your friend? All you actually have is a system which identifies messages as having come from consistent sources - not one that guarantees the message was actually written by who it says it was!
OpenID isn't based on the idea that you enter a URL into a site and have that site blindly trust it. A three-way handshake takes place: the site you're logging into asks your OpenID provider, which in turn asks *you*, via whatever means it desires (as long as it's web-based), to prove that: * You own the OpenID account being used (username & password) * You give the site you're logging into permission to grab the information it's after (which could be anything from simply being allowed to receive a "yes" response, to knowing your pet's mother's maiden name, depending on what OpenID extensions - if any - are in use).
As the GP said, the spammer would need to compromise either the site being logged into, or the OpenID provider's site, if they wanted to forge posts.
Alternatively, I could just create a really sh*t website that allowed anyone to enter any name & details they liked, any time they posted, and feign authority in saying that this person really did post these comments. But that wouldn't become a trusted or popular website, would it?
This is a very important point, and the key to any notion of security surrounding OpenID. It is in essence a three-way handshake between the site you're logging in to, your browser, and your OpenID provider, with your actual username and password only ever being passed between the second to. When I first heard about OpenID, I was highly skeptical - then I read the specs in detail, and came round to the idea.
You are missing a certain amount of point here: not everybody has, or necessarily wants, their own website. People will be relying on third-party OpenID servers; LiveJournal, possibly the first and certainly the most well-known site to have adopted OpenID, is likely to be a fairly common choice. There already exist a handful of free OpenID servers on the net that are just that (i.e. not also a blogging service or anything else). However, for those of us who do have their own website, I see OpenID's killer feature being delegation: a couple of meta tags in your site's front page, and you can authenticate as your own website without having to set up your own OpenID server. I have done this on my own blog, for which I have rolled my own mini-CMS - with OpenID identification for comments, natch.
Delegation in plain English: * Johnny owns www.a.com. Johnny is lazy; he only wants to implement an ID consumer, not a provider. * Kate runs www.b.com, a free OpenID provider; Johnny trusts Kate, so he opens an account there. * By inserting delegation tags into the relevant page on www.a.com, Johnny can authenticate as www.a.com with any consumer, with www.b.com doing all the donkey work. * If www.b.com goes belly-up or gets compromised, Johnny simply opens a new account elsewhere, changes his delegation tags to reflect the new provider, and keeps using www.a.com as his identity.
I have personal experience with OpenID, having both created and used an OpenID account, and of course running the aforementioned blog. It's very cool: I can post as mangobrain.co.uk to the LiveJournals I read, and people from LiveJournal can post as themselves on my own site, providing both fairly trustworthy identification and automatic linking for robots to pick up on.
Since when was "social networking" a computer skill? Kids have been going to friend's houses, going to youth clubs, going to music/dance/martial arts etc. classes after school, going to each other's birthday parties, and just generally hanging out for a very, very long time. They've also been making pen friends. I once met someone on IRC from the other side of the world, and although that initial meeting was online, almost all of our correspondence from then until losing touch years later was by letter (the real, pen and paper kind).
To my mind, a "computer skill" is a skill related to the intrinsics of computers themselves, be it hardware or software, or the ability to do something you actually or effectively cannot do without computers. Simply knowing how to use computers is "computer literacy"; for me, at least, the distinction is the very reason we have two separate terms.
And they are already fixing packaging problems: 2.5-r1
Bear in mind Gentoo may take longer than most to fully switch over to 2.5, since Portage itself is written in Python. They have much more to lose from getting this wrong than Debian. I have used Debian in the past, but have been a Gentoo user for a few years now; I have noticied a backing off - intentional or otherwise - from the old "bleeding edge" tendencies over the past few months, but I for one am not particularly bothered, provided it isn't indicative of infrastructure problems and doesn't become a growing trend of getting further and further behind. (I have no evidence that it is either of these things, just a bad gut feeling based on some of the not-so-good times I've had with the distro.)
Backwards compatibility? Yes, backwards!
on
Python 2.5 Released
·
· Score: 1
Err... I think you have your definitions mixed up. Forward compatibility is the ability to accept (even if "accept" simply means ignore without error) input that is designed for future use - for example, Python 2.4 would be forwards compatible with 2.5 if you could use it to run code containing "with" statements, accepting the caveat that the code blocks they contained wouldn't be executed (but would "magically" begin to work if you switched to 2.5 - AFAIK, 2.4 is NOT forward compatible in this manner, this is simply an example). A more useful example is in HTML, where forwards compatibility is achieved by browsers simply ignoring tags they do not understand, and treating their content as plaintext - this is how the "noscript" tag works: old browsers ignore the tag and print the content, new browsers know to pretend both tag and content aren't there when JavaScript is available.
Backward compatibility would be the ability of Python 2.5 to completely replace Python 2.4 in current usage scenarios with code changes on the level of little to none. It is the ability of a new version of a system to accept input designed for an older version, and still produce sane, expected output.
The ability to communicate ideas is quite a fundamental point in if you are, or are going to become, a programming professional. The term "backwards compatible" should be in every serious programmer's vocabulary, and I have yet to use it in a face-to-face conversation a programmer who so much as hinted that they didn't think it meant exactly the same thing I do. Forward compatibility is less common; in fact, I actually had to look up a definition to check I had the right idea!
Point 2 - "well-configured on Linux" should read "well-configured on Linux".
Point 10 - "Yes, I know an awful lot of people and interfaces use 'login', and variations thereon;... " should read "Yes, I know an awful lot of people and interfaces use 'login', and variations thereon, as nouns;... ".
Point 12 - "Hint: it was a bug you encountered in the first sentence, not a feature." Replace "first" with 'second'.
Point 13 - "intended to pointing" should read "intended to point".
Only bothered with the above since I made a point of criticising grammar in TFA. I did write this stuff at 4AM, though, so please forgive me.:)
It's intended as a kind of open letter - and yes, I know, authors of these articles aren't going to go to Slashdot and read every article. I was thinking of emailing it to him personally as well (corrected, of course).
1. "Microsoft is building some of the most ambitious security components of Windows Vista not for its customers, but for itself." Well, duh.
2. "With Beta 2 running on multiple test units, I feel comfortable predicting that Windows Vista will not outpace Mac OS X Tiger for overall quality and usability." Have you ever tried to be truly productive with Mac OS X compared to well-configured on Linux? I have tried and failed. I am greatly uncomfortable with window-specific menu functions residing in a session-wide screen fixture instead of windows themselves, cannot tell the difference between launchers and running applications when looking at the dock, and generally find it excruciatingly painful to perform tasks that are, on other systems, second nature to me.
3. "I see Linux and Windows 2000 as being roughly tied another notch or two below Vista, with XP being only a half step better than Win 2000." Your article is concerned mostly with GUI changes. Do you realise how many window managers, GUI toolkits, and "desktop environments" are available on Linux? Also, do you know that modern Linux (and/or generic UNIX) applications and environments can replicate, after a fashion, all of Vista's big graphical and usability improvements? However, I must admit that some of the software I'm referring to is itself beta at best.
4. "It's also intent on raising the bar to 64-bit architecture, driving the need for advanced video hardware and dual-core motherboards and pushing the RAM standard to 2GB -- all to help spur hardware and software sales over the next several years." Well, seen from a purely capitalist point of view, you got the motivation right. From a developer's point of view, you missed the fact that they don't seem the slightest bit interested in reducing bloat - yet point out elsewhere how smooth Mac OS X's visual effects are on less powerful hardware. "Although the cool video features in Vista Aero are nice, Apple was able to provide a lot of the same functionality working with my Power PC-based Mac Mini M9687LL/A, which has only 32MB of video RAM."
5. "With notebooks becoming the primary form factor in many companies and homes, the artificially short half-lives of these computers need to be lengthened." Half-lives? Laptop computers (sorry, I point-blank refuse to call them "notebooks") are radioactive, are they? I also despise the phrase "form factor", although I can't fault you specifically more than I can fault anyone else who uses this horrible phrase.
6. "more main-system RAM hungry". Here's a tip: don't invent long-winded, annoying-sounding phrases just because you think they sound more 'technical' than existing ones ('memory hungry'). Is that "main-system" as opposed to additional-system RAM? Perhaps it can dynamically borrow RAM from other systems one has lying around?
7. "Windows NT, 2000 and XP have always had log-in-based system privileges, but they're cumbmersome." On the Web, nobody can hear you proof-read.
8. "Given that both Linux and the Mac require users to authenticate.... or, in Linux's case, to log in as root, which requires authentication". Sorry, I'm not quite sure I understood the requirements; could you just run them by me once more?
9. "Vista requires you to create an administrator-class account name as part of installation or first boot, eliminating a major vulnerability. That means, by default, no one is running with the Administrator log-in." When I installed Windows 2000, it asked me to enter a password for the administrator account - sounds like creating an administrator-class account to me. Plus it isn't obvious from the quote, or its context, exactly how this prevents people using the Administrator account. Stop and think: remember that your subject matter is an unreleased operating system, and that Joe Public is at present likely to be entirely unaware that "administrator-class" and "Administrator" refer to two different concepts; then, bearing that fact in mind, read the sentences back to yourself. You will find th
When it comes to programming, I'm not a "kid", and I don't take kindly to being called one. I have used VB a small amount, and Delphi quite extensively; in fact, I actually grew to like Delphi. I'm not against RAD tools per se - you have completely and utterly missed my point. In actual fact, I mentioned neither C++ nor assembly language in my post.
My point is this: if you did decide to write your "business apps" in C++ or assembly, there wouldn't be anything technically stopping you (and C++ in particular has such a wealth of libraries on a wealth of platforms that it might in fact be a good idea); on the other hand, there ARE things you can't do with RAD tools - at least not without jumping through many more hoops than is sensible. Hence, RAD tools are not highly regarded as general purpose development tools, and people whose programming work is slightly more varied and in-depth than tedious data management GUIs tend to steer well clear. Auto-generated code can make people very lazy: if someone cannot instantly get the tool to produce a program which works like their original vision, they'll make something "good enough" (which often isn't even that) and stop, instead of taking the time to bend and shape the code to fit. I've witnessed it first-hand many times; Delphi was the teaching language in use at my university, and I did a stint as an undergraduate CS lab assistant.
If you really want to go around calling yourself a programmer, then you cannot realistically learn to use one RAD tool and stop. Call yourself a "VB programmer", perhaps, but not a "programmer" outright.
I like to pick the right tool for the job. As I have already pointed out, I mentioned neither C++ nor assembly language; in actual fact, I learnt to program in BBC BASIC, and now program in C/C++, Perl, Python and PHP on a regular basis, and begrudge none of them their place in my skill set. I don't necessarily consider knowing 4 languages to be any great achievement; these are just the four I'm currently active in (I already mentioned Delphi, VB and BBC BASIC, making at least 7 in total), and I enjoy learning more as necessary.
I don't work in a technology company - I work for a firewall/security software manufacturer, specifically on web content & anti-virus filtering. I do occasionally have to solve "data problems", namely turning user input from a CGI web interface into valid program configuration files, and I don't use a RAD. Given the requirements at hand, I think VB would be about the least appropriate tool for the job, whereas any one of Perl, Python, PHP, C/C++, Java etc. could realistically be used, with varying degrees of difficulty.
You never had a "data problem" you couldn't solve with it? Good for you. Now go and use it to do something other than "solve data problems", e.g. write a scalable network server, a high-performance 3D engine, or a device driver.
Ahh, BASIC. The very name is an acronym for (IIRC) "Beginner's All-purpose Symbolic Instruction Code". Notice the capitalisation in "Visual Basic"? That's right: it's basic, but it ain't BASIC.
True BASIC should be interactive. By this I mean you tell the computer what to do, and it does it; beginners should not have to jump through hoops setting up a development environment, they should not have to deal with compilers, and ideally they should not even have to open a text editor. It is also important to note my wording of the phrase "you TELL THE COMPUTER what to do". It's like a discussion: you say "JUMP", it says "Syntax error: height not specified".
You see, there was a time when, for the interested user, computers made programming easy and accessible. When programming was full-screen, interactive and fun, and computers came with manuals - useful, interesting manuals, neither pointless fluffy Windows XP pamphlets nor weighty tomes such as the archetypal UNIX manual.
I started programming on an Acorn Archimedes with RISC OS 2, and I wouldn't change the experience for the world. In everyday use, you had a powerful, multitasking WIMP interface with features still being mimicked to this day; however, by pressing F12 and running the "basic" command, you entered another world. In this world, if you tell the computer to PRINT "Hello World", it prints Hello World. If you ask it "HELP.", it gives you a list of all keywords, which sits very happily on one screen. If you ask it to "CIRCLEFILL 60,512,100" you get a filled circle, at the middle of the screen, 100 pixel radius, and still get returned a command prompt - and why not? It's your computer, BASIC is the tool designed to make the computer "do stuff", and if "stuff" means give me pixel-level screen control which co-exists with the input prompt and doesn't take half an hour messing around with graphics APIs, then I'll damn well do just that. If I want to store my programs, I can use the line editing commands; when I've outgrown that, I can use a text editor straight from the WIMP and launch saved programs just by clicking on them. It's a computer; it does stuff, it's easy to make it do so, and it all came for free.
If you want, you can buy the more expensive manuals, the ones which don't come with the computer. Then you can learn how to make OS API calls, use the more advanced facilities of the graphics hardware, and even use BASIC to bootstrap assembly code. I never owned these manuals, but it didn't stop me trying. The point is: experimentation was fun, easy and encouraged.
When we got our first Windows 98 PC (completely bypassing both DOS and 95), for the first few years I still went back to the Acorn to program: after all, the Windows machine didn't come with any programming tools; what a gyp! Can you imagine my disappointment? It wasn't until I discovered Linux and FOSS that I finally stopped going back to the Acorn whenever I felt the urge to hack, and even then it took a while.
I now have an MEng. in Computer Science and Cybernetics; program in Perl, Python, PHP and C/C++ (depending on the task at hand) on a regular (and paid) basis; I understand the tradeoff between fast programs and fast development times. I cannot stand VB; it is a mess. I grew to like Delphi - the teaching language - whilst at uni, but when I can't make it do what I want, I'll go create a command-line utility in C that does it, then hit Object Pascal until I get an equivalent algorithm out of it. To this day, I still use text terminals under Linux on a daily basis, and insist on binding F12 to open a terminal emulator in Gnome. Python's interactive mode is probably the closest thing I've seen in years to good ol' BBC BASIC, but it still doesn't give you fully integrated graphics and sound control - I understand why (portability concerns; device driver issues; the contemporary expectation that programming environments are "just a tool" and should behave like just another window on the desktop), but that doesn't mean I have to like it.
Well its predecessor - the GP32 - existed, sold, and didn't cause the company to get sued into the ground. Just to point out that these people have a track record.
Also, if you don't use WMV or WMA formats at the moment, why does it matter to you personally whether and how the device plays then? Even MP3 is patented. I'm more interested in the claimed Ogg Vorbis and XviD support.:)
Don't worry about it. I just pre-ordered one (yay!) from FF with no problems - the actual card details are entered on a seperate, SSLed site, which then drops you back to the gp2x site and gives you your order number. They're just covering their backs.
...in terms of media support and homebrew development? The GP2X supports Ogg Vorbis and DivX amongst others, and possibly even XviD (correct me if I'm wrong; I'm sure I read about it somewhere, just can't find a reference on the new site). It's a very tempting piece of hardware.
However, the XGP - comparitively ugly as it may be, if you ask me - has a larger screen and supports OpenGL ES, tempting to me as a developer. But I have no idea whether it's intended to be an open platform; or, if it's not, whether it has decent codec support (WHY are there so few portable ogg players?).
I think the parent was talking about it being a downgrade compared to the original GP32, not the XGP (the "other" console on the link you posted), which is an entirely different, also new handheld. I don't know the details, but the original Gamepark is now split into two companies, each releasing a different product.
I didn't know about said extension, and I for one have never used it, nor know anyone personally who does. Nor can a (very brief, admittedly) stint with Google or mozdev turn up such a thing. I'm not saying it doesn't exist - but if it does, it's not perhaps as commonly used as you think.
I've also suffered from very few (possible none) IE exploits on my machine, but the "family" PC - a winXP box - used to be forever getting hit with spyware, adware, things transparently replacing the home page/search function, and so on and so forth. (Yes, I switched it over to Firefox the best part of a year ago now, but the problems with spy/adware aren't completely gone - largely due to my mum's free game habit and my sister's kazaa addiction.)
You and I know what we're doing with our computers. To the people using the box downstairs in the kitchen, it's just a tool, they don't want to have to think about such things.
Slashdot Mirror
Every man and their dog seems to be mentioning Eclipse, and I've seen a couple of mentions of KDevelop, but nobody has mentioned Anjuta. I've tried Eclipse briefly, and found it highly confusing - I must admit I gave up fairly quickly. I haven't tried KDevelop, and don't particularly want to, because I've never liked KDE or Qt and don't want the libraries taking up valuable space and time (yes, I use Gentoo - go on, laugh if you like :P ) on my machine.
Now, Anjuta claims to be written in - and for - GTK/GNOME, but in reality it's just a GTK front-end to the Autotools and GDB which happens to come with a collection of GTK-oriented project templates. I must admit to not knowing what Eclipse and KDevelop generate in terms of a build system for projects, but what I like most about Anjuta is that it uses the Autotools completely and utterly: adding sources and targets (programs/libraries) simply adds entries into the relevant Makefile.am files, adding external library dependencies (it can automatically find and add support for anything on the system which uses pkg-config) adds to configure.ac, and those files are the *only* place that information is stored. When you load an "Anjuta project" up, it re-creates the project hierarchy by parsing those files back in; it doesn't store any metadata you'd be particularly bothered about losing, which means that if the person sat next to me wants to, they can work on the exact same project using Vim and a terminal. After all, building the project is no more difficult than any other Autotools package. :)
Its GDB integration is good, the editors - you can choose either a Scintilla-based one or a GtkSourceView-based one - are capable, and if you *do* happen to want to develop a GTK/GNOME app, things like DevHelp integration just help make life easier and make the whole thing feel that little bit more "professional". My only real complaint is that it can't automatically write configure scripts to look for non pkg-config libraries, but I know how difficult that can be for humans at the best of times. ;)
I'm not excusing the complete and utter stupidity of Vista's behaviour, but:
The work being done here is, essentially, taking existing 3D game content and rendering it using a raytracer. One of the benefits of raytracing is that it can render real curved surfaces, including NURBS and volumetric surfaces: without taking advantage of this aspect of the technology, would we really see much visual benefit? Hard-edged shadows are already possible with rasterizers, and a lot of the potential for visual quality in refractive surfaces (glass) would be lost without real curves: it wouldn't necessarily look much better than the existing approximations. It might just be that what we're looking at here is effectively "programmer art", but hard-edged shadows, flat textured surfaces and overly-shiny metallic objects can look worse than current rasterized graphics. Who, when creating a modern computer game, thinks "I wish I could render a perfect sphere here" or "A reflective torus would look brilliant in the centre of this room"? Mathematically and algorithmically pleasing or not, plastic-y graphics won't cut it in the real world.
We won't be getting away from polygons any time soon because realism comes less from simulating perfect surfaces, and more from *imperfect* surfaces. Note how much work is being done to increase the level of imperfections in our graphics: higher detail textures, bump mapping, increased polygon counts specifically aimed at removing the need for large flat areas.
3D modellers don't create mathematically perfect shapes. Since we won't be going away from polygons any time soon, and the visual benefits of raytracing have largely been simulated well enough already, it all comes down to whether or not the *performance* of raytracing will eventually outstrip rasterizers, since the *quality* issue is almost a moot point. Now, show me realtime path-tracing or global illumination and I'll be more convinced.
Not that I don't like raytracers. I've written one, and spent my final year at uni optimising it (just for a masters, not for a doctorate, so it wasn't exactly ground-breaking work). Just not convinced they're the right tool for the job, seeing as in their purest form, they've already been supplanted.
1 ray per pixel? Not true if you want light sources other than "ambient" (shadows or otherwise) or reflections. One ray per pixel to discover which object is visible at that point, then one ray per lightsource to find out whether or not it is casting light on the point of intersection, plus at least one more ray if the surface is reflective. If you want to render shadows in reflections, and nested reflections, the algorithm becomes recursive. Also, for each ray, you need to calculate which of the "thousands to millions" of triangles it intersects with - the algorithm being effectively both forking and recursive if you want translucency (shadow rays, reflective rays etc. need to be cast from the surface of the translucent object, *and* whatever object(s) are visible behind it).
Put simply: raytracing doesn't intrinsically scale with number of objects better than traditional rasterizers. With naive implementations of intersection tests, it can scale *worse*.
Disclaimer: I haven't actually tried this, and so may be talking utter BS. However...
Surely the shell will expand 'rm *' such that the listing will include anything in the current directory, regardless of name? That should, in this case, get a literal '*' inserted into the arguments that get passed to 'rm'. Since it's reasonable to assume that the shell won't try to expand arguments recursively, and that 'rm' neither has its own expansion routines (duplicating functionality from the shell) nor is itself a shell script, the file '*' will be deleted just fine.
Alternatively, couldn't you just run 'rm \*'?Not quite sure what's so "interesting" about this one.
I once typed 'rm -rf /etc' on my box at work instead of 'rm -rf etc'. I was attempting to clean out part of either a virtual machine or chroot environment (I forget which), but unfortunately ended up running the command on the host itself.
Working for a company whose product is at its core a specialised Linux distro leads to all sorts of confusing moments - it's not uncommon for me to have my machine running two or three instances of QEMU running our products (with at least one more running Windows on the same virtual network), two or three terminals open on the host (which may or may not be running an SSH session to one of the virtual machines), an SSHFS mount point or two on the host to the guest's file systems, and a copy of our build environment, a fully-fledged chroot environment with its own toolchain (which is also a Subversion working copy, but can only be usefully used as such whilst not chrooted).
The best part is that I was able to stop the command half-way through and actually recover the system without a reinstall - in fact, I'm still using the same install of the same OS to this day (this was about a year ago now). This was/is Gentoo (as developers we get free reign over our own machines, the only requirement being that our choice of OS can build - or be persuaded to build without too much hassle - a local copy of our build environment); I had to recreate a few important things such as /etc/make.conf and /etc/profile, but since I basically still had a working build environment and was logged in as root when having run The Command, I was able to get the rest back eventually (as long as I didn't log out, and as long as I didn't mind losing the rest of that working day compiling stuff).
There are laws there to protect a lot of things. To give a somewhat extreme example, there are laws that say it's the driver's fault if I get run over whilst cycling (in some countries/circumstances) - but those laws won't magically rush in and pull me out at the last second, or reinforce my cycle helmet such that it can withstand speeding lorries, or anything of the sort. You can't benefit from compensation if you're dead.
My point is this: given a compiled (i.e. non-human-readable) executable file, can you tell whether or not the source code from which it was compiled violates any licenses? Not realistically, no. Being illegal doesn't stop a lot of people from doing a lot of things, or we'd probably have achieved world peace already. Laws are also not automatically enforceable by merit of existence.
That said, I don't think this search engine will encourage anyone to commit licensing violations who isn't already perfectly happy doing so (or ignorant of what they're doing). I just don't think legality has anything to do with it, unfortunately.
They may be able to "steal" an old OpenID URL in the sense that they are now able to identify themselves as owning it, where previously you identified yourself as owning it. However as I said in my original post, they do NOT automatically steal any more personal information you might have associated with your OpenID, such as financial details. This would only happen if your OpenID provider was hacked into, or if you were running the provider yourself, and they inherited the whole server - disk contents and all - rather than just the domain name.
If you want to keep your OpenID URL constant, then yes, you do need to maintain ownership of that URL, regardless of whether you're using delegation. However if you are using delegation, then you can lose your entire web hosting account and simply start using the non-delegated URL directly without having to re-enter any other information you had stored in your OpenID account.
I see two scenarios:
There is nothing to stop an OpenID-enabled site from taking simple details - such as name, email address, age - from your OpenID profile automatically, and allowing you access to features which simply require an identity (e.g. comment posting), but then optionally require some site-specific secret on top of that in order to use features which require trust (e.g. financial transactions). True, this goes against the holy grail of single sign-on, but it is one way to add a trust layer to a system which, due to its decentralised nature, can never guarantee that old identities do not get re-assigned. There may be other, more elegant solutions, but it is important to notice the need for such a layer.
Continuing on the theme of e-commerce, is there a need for a trust layer in the event that OpenID consumers never cache sensitive data? Someone could steal your OpenID URL and sign in to a shopping site you've used, but unless they have already stolen your credit card number by some other means, their OpenID provider will not be able to give that information out, because it won't know it (assuming your OpenID provider has remained secure).
If www.a.com goes away, his account on www.b.com is still perfectly usable; he can either start using its OpenID URL directly, or get a new website and delegate that one to it. True, he can no longer identify himself as www.a.com, but the system can't be so decentralised that even the ID you present is not constant - wouldn't it kind of defeat the point of an identification framework if everybody's ID was always changing?
If Johnny owns and operates www.a.com and it goes away for a reason such as non-payment, he has nobody else to blame; other than that, it's just a case of picking reliable providers. Have you never had to change your email address, or played around with cheap webhosting only to abandon the account later (possibly for reasons outside your control)? These two problems are not specific to OpenID, I would argue.
A more interesting one, which does concern me, is what might happen if Johnny loses his domain name and it gets snapped up by someone else, who then creates an OpenID account and posts on all Johnny's old haunts pretending to be him. How do you protect against that? But then again, the system is more about identification than authentication*. If, for example, someone created an extension to OpenID for the storage of payment details - not that I personally think this would be an appropriate usage of the system - then losing his domain name might mean he has to start identifying himself via a different URL, but the domain's next owner hasn't magically gained access to his credit card number (which is still locked away by his OpenID provider, and as secure as their site is).
Anyone considering forming a serious attachment to an OpenID URL needs to pick one they are confident they can hold on to, delegated or otherwise. My personal usage of the framework has been as a rudimentary anti-spam system (requring *any* form of authentication is a barrier of sorts to automated posting, especially for low-profile, personal sites), as a way to identify myself when leaving comments on friend's LJ blogs, and as a way for them to identify themselves on my own blog without the hassle of signing up for it specifically.
* There is a difference between the two; authentication implies trust. Example: if you imported a GPG key bearing a friend's name from a public keyserver, without asking them in person whether this key does actually belong to them, is a message signed by that key guaranteed to actually have been written by your friend? All you actually have is a system which identifies messages as having come from consistent sources - not one that guarantees the message was actually written by who it says it was!
OpenID isn't based on the idea that you enter a URL into a site and have that site blindly trust it. A three-way handshake takes place: the site you're logging into asks your OpenID provider, which in turn asks *you*, via whatever means it desires (as long as it's web-based), to prove that:
* You own the OpenID account being used (username & password)
* You give the site you're logging into permission to grab the information it's after (which could be anything from simply being allowed to receive a "yes" response, to knowing your pet's mother's maiden name, depending on what OpenID extensions - if any - are in use).
As the GP said, the spammer would need to compromise either the site being logged into, or the OpenID provider's site, if they wanted to forge posts.
Alternatively, I could just create a really sh*t website that allowed anyone to enter any name & details they liked, any time they posted, and feign authority in saying that this person really did post these comments. But that wouldn't become a trusted or popular website, would it?
This is a very important point, and the key to any notion of security surrounding OpenID. It is in essence a three-way handshake between the site you're logging in to, your browser, and your OpenID provider, with your actual username and password only ever being passed between the second to.
When I first heard about OpenID, I was highly skeptical - then I read the specs in detail, and came round to the idea.
You are missing a certain amount of point here: not everybody has, or necessarily wants, their own website. People will be relying on third-party OpenID servers; LiveJournal, possibly the first and certainly the most well-known site to have adopted OpenID, is likely to be a fairly common choice. There already exist a handful of free OpenID servers on the net that are just that (i.e. not also a blogging service or anything else).
However, for those of us who do have their own website, I see OpenID's killer feature being delegation: a couple of meta tags in your site's front page, and you can authenticate as your own website without having to set up your own OpenID server. I have done this on my own blog, for which I have rolled my own mini-CMS - with OpenID identification for comments, natch.
Delegation in plain English:
* Johnny owns www.a.com. Johnny is lazy; he only wants to implement an ID consumer, not a provider.
* Kate runs www.b.com, a free OpenID provider; Johnny trusts Kate, so he opens an account there.
* By inserting delegation tags into the relevant page on www.a.com, Johnny can authenticate as www.a.com with any consumer, with www.b.com doing all the donkey work.
* If www.b.com goes belly-up or gets compromised, Johnny simply opens a new account elsewhere, changes his delegation tags to reflect the new provider, and keeps using www.a.com as his identity.
I have personal experience with OpenID, having both created and used an OpenID account, and of course running the aforementioned blog. It's very cool: I can post as mangobrain.co.uk to the LiveJournals I read, and people from LiveJournal can post as themselves on my own site, providing both fairly trustworthy identification and automatic linking for robots to pick up on.
Since when was "social networking" a computer skill? Kids have been going to friend's houses, going to youth clubs, going to music/dance/martial arts etc. classes after school, going to each other's birthday parties, and just generally hanging out for a very, very long time. They've also been making pen friends. I once met someone on IRC from the other side of the world, and although that initial meeting was online, almost all of our correspondence from then until losing touch years later was by letter (the real, pen and paper kind).
To my mind, a "computer skill" is a skill related to the intrinsics of computers themselves, be it hardware or software, or the ability to do something you actually or effectively cannot do without computers. Simply knowing how to use computers is "computer literacy"; for me, at least, the distinction is the very reason we have two separate terms.
It is there: Python 2.5
And they are already fixing packaging problems: 2.5-r1
Bear in mind Gentoo may take longer than most to fully switch over to 2.5, since Portage itself is written in Python. They have much more to lose from getting this wrong than Debian. I have used Debian in the past, but have been a Gentoo user for a few years now; I have noticied a backing off - intentional or otherwise - from the old "bleeding edge" tendencies over the past few months, but I for one am not particularly bothered, provided it isn't indicative of infrastructure problems and doesn't become a growing trend of getting further and further behind. (I have no evidence that it is either of these things, just a bad gut feeling based on some of the not-so-good times I've had with the distro.)
Err... I think you have your definitions mixed up. Forward compatibility is the ability to accept (even if "accept" simply means ignore without error) input that is designed for future use - for example, Python 2.4 would be forwards compatible with 2.5 if you could use it to run code containing "with" statements, accepting the caveat that the code blocks they contained wouldn't be executed (but would "magically" begin to work if you switched to 2.5 - AFAIK, 2.4 is NOT forward compatible in this manner, this is simply an example). A more useful example is in HTML, where forwards compatibility is achieved by browsers simply ignoring tags they do not understand, and treating their content as plaintext - this is how the "noscript" tag works: old browsers ignore the tag and print the content, new browsers know to pretend both tag and content aren't there when JavaScript is available.
Backward compatibility would be the ability of Python 2.5 to completely replace Python 2.4 in current usage scenarios with code changes on the level of little to none. It is the ability of a new version of a system to accept input designed for an older version, and still produce sane, expected output.
The ability to communicate ideas is quite a fundamental point in if you are, or are going to become, a programming professional. The term "backwards compatible" should be in every serious programmer's vocabulary, and I have yet to use it in a face-to-face conversation a programmer who so much as hinted that they didn't think it meant exactly the same thing I do. Forward compatibility is less common; in fact, I actually had to look up a definition to check I had the right idea!
Point 2 - "well-configured on Linux" should read "well-configured on Linux".
... " should read "Yes, I know an awful lot of people and interfaces use 'login', and variations thereon, as nouns; ... ".
:)
Point 10 - "Yes, I know an awful lot of people and interfaces use 'login', and variations thereon;
Point 12 - "Hint: it was a bug you encountered in the first sentence, not a feature." Replace "first" with 'second'.
Point 13 - "intended to pointing" should read "intended to point".
Only bothered with the above since I made a point of criticising grammar in TFA. I did write this stuff at 4AM, though, so please forgive me.
It's intended as a kind of open letter - and yes, I know, authors of these articles aren't going to go to Slashdot and read every article. I was thinking of emailing it to him personally as well (corrected, of course).
1. "Microsoft is building some of the most ambitious security components of Windows Vista not for its customers, but for itself." Well, duh.
.... or, in Linux's case, to log in as root, which requires authentication". Sorry, I'm not quite sure I understood the requirements; could you just run them by me once more?
2. "With Beta 2 running on multiple test units, I feel comfortable predicting that Windows Vista will not outpace Mac OS X Tiger for overall quality and usability." Have you ever tried to be truly productive with Mac OS X compared to well-configured on Linux? I have tried and failed. I am greatly uncomfortable with window-specific menu functions residing in a session-wide screen fixture instead of windows themselves, cannot tell the difference between launchers and running applications when looking at the dock, and generally find it excruciatingly painful to perform tasks that are, on other systems, second nature to me.
3. "I see Linux and Windows 2000 as being roughly tied another notch or two below Vista, with XP being only a half step better than Win 2000." Your article is concerned mostly with GUI changes. Do you realise how many window managers, GUI toolkits, and "desktop environments" are available on Linux? Also, do you know that modern Linux (and/or generic UNIX) applications and environments can replicate, after a fashion, all of Vista's big graphical and usability improvements? However, I must admit that some of the software I'm referring to is itself beta at best.
4. "It's also intent on raising the bar to 64-bit architecture, driving the need for advanced video hardware and dual-core motherboards and pushing the RAM standard to 2GB -- all to help spur hardware and software sales over the next several years." Well, seen from a purely capitalist point of view, you got the motivation right. From a developer's point of view, you missed the fact that they don't seem the slightest bit interested in reducing bloat - yet point out elsewhere how smooth Mac OS X's visual effects are on less powerful hardware. "Although the cool video features in Vista Aero are nice, Apple was able to provide a lot of the same functionality working with my Power PC-based Mac Mini M9687LL/A, which has only 32MB of video RAM."
5. "With notebooks becoming the primary form factor in many companies and homes, the artificially short half-lives of these computers need to be lengthened." Half-lives? Laptop computers (sorry, I point-blank refuse to call them "notebooks") are radioactive, are they? I also despise the phrase "form factor", although I can't fault you specifically more than I can fault anyone else who uses this horrible phrase.
6. "more main-system RAM hungry". Here's a tip: don't invent long-winded, annoying-sounding phrases just because you think they sound more 'technical' than existing ones ('memory hungry'). Is that "main-system" as opposed to additional-system RAM? Perhaps it can dynamically borrow RAM from other systems one has lying around?
7. "Windows NT, 2000 and XP have always had log-in-based system privileges, but they're cumbmersome." On the Web, nobody can hear you proof-read.
8. "Given that both Linux and the Mac require users to authenticate
9. "Vista requires you to create an administrator-class account name as part of installation or first boot, eliminating a major vulnerability. That means, by default, no one is running with the Administrator log-in." When I installed Windows 2000, it asked me to enter a password for the administrator account - sounds like creating an administrator-class account to me. Plus it isn't obvious from the quote, or its context, exactly how this prevents people using the Administrator account. Stop and think: remember that your subject matter is an unreleased operating system, and that Joe Public is at present likely to be entirely unaware that "administrator-class" and "Administrator" refer to two different concepts; then, bearing that fact in mind, read the sentences back to yourself. You will find th
When it comes to programming, I'm not a "kid", and I don't take kindly to being called one. I have used VB a small amount, and Delphi quite extensively; in fact, I actually grew to like Delphi. I'm not against RAD tools per se - you have completely and utterly missed my point. In actual fact, I mentioned neither C++ nor assembly language in my post.
My point is this: if you did decide to write your "business apps" in C++ or assembly, there wouldn't be anything technically stopping you (and C++ in particular has such a wealth of libraries on a wealth of platforms that it might in fact be a good idea); on the other hand, there ARE things you can't do with RAD tools - at least not without jumping through many more hoops than is sensible. Hence, RAD tools are not highly regarded as general purpose development tools, and people whose programming work is slightly more varied and in-depth than tedious data management GUIs tend to steer well clear. Auto-generated code can make people very lazy: if someone cannot instantly get the tool to produce a program which works like their original vision, they'll make something "good enough" (which often isn't even that) and stop, instead of taking the time to bend and shape the code to fit. I've witnessed it first-hand many times; Delphi was the teaching language in use at my university, and I did a stint as an undergraduate CS lab assistant.
If you really want to go around calling yourself a programmer, then you cannot realistically learn to use one RAD tool and stop. Call yourself a "VB programmer", perhaps, but not a "programmer" outright.
I like to pick the right tool for the job. As I have already pointed out, I mentioned neither C++ nor assembly language; in actual fact, I learnt to program in BBC BASIC, and now program in C/C++, Perl, Python and PHP on a regular basis, and begrudge none of them their place in my skill set. I don't necessarily consider knowing 4 languages to be any great achievement; these are just the four I'm currently active in (I already mentioned Delphi, VB and BBC BASIC, making at least 7 in total), and I enjoy learning more as necessary.
I don't work in a technology company - I work for a firewall/security software manufacturer, specifically on web content & anti-virus filtering. I do occasionally have to solve "data problems", namely turning user input from a CGI web interface into valid program configuration files, and I don't use a RAD. Given the requirements at hand, I think VB would be about the least appropriate tool for the job, whereas any one of Perl, Python, PHP, C/C++, Java etc. could realistically be used, with varying degrees of difficulty.
You never had a "data problem" you couldn't solve with it? Good for you. Now go and use it to do something other than "solve data problems", e.g. write a scalable network server, a high-performance 3D engine, or a device driver.
Ahh, BASIC. The very name is an acronym for (IIRC) "Beginner's All-purpose Symbolic Instruction Code". Notice the capitalisation in "Visual Basic"? That's right: it's basic, but it ain't BASIC.
.", it gives you a list of all keywords, which sits very happily on one screen. If you ask it to "CIRCLEFILL 60,512,100" you get a filled circle, at the middle of the screen, 100 pixel radius, and still get returned a command prompt - and why not? It's your computer, BASIC is the tool designed to make the computer "do stuff", and if "stuff" means give me pixel-level screen control which co-exists with the input prompt and doesn't take half an hour messing around with graphics APIs, then I'll damn well do just that. If I want to store my programs, I can use the line editing commands; when I've outgrown that, I can use a text editor straight from the WIMP and launch saved programs just by clicking on them. It's a computer; it does stuff, it's easy to make it do so, and it all came for free.
True BASIC should be interactive. By this I mean you tell the computer what to do, and it does it; beginners should not have to jump through hoops setting up a development environment, they should not have to deal with compilers, and ideally they should not even have to open a text editor. It is also important to note my wording of the phrase "you TELL THE COMPUTER what to do". It's like a discussion: you say "JUMP", it says "Syntax error: height not specified".
You see, there was a time when, for the interested user, computers made programming easy and accessible. When programming was full-screen, interactive and fun, and computers came with manuals - useful, interesting manuals, neither pointless fluffy Windows XP pamphlets nor weighty tomes such as the archetypal UNIX manual.
I started programming on an Acorn Archimedes with RISC OS 2, and I wouldn't change the experience for the world. In everyday use, you had a powerful, multitasking WIMP interface with features still being mimicked to this day; however, by pressing F12 and running the "basic" command, you entered another world. In this world, if you tell the computer to PRINT "Hello World", it prints Hello World. If you ask it "HELP
If you want, you can buy the more expensive manuals, the ones which don't come with the computer. Then you can learn how to make OS API calls, use the more advanced facilities of the graphics hardware, and even use BASIC to bootstrap assembly code. I never owned these manuals, but it didn't stop me trying. The point is: experimentation was fun, easy and encouraged.
When we got our first Windows 98 PC (completely bypassing both DOS and 95), for the first few years I still went back to the Acorn to program: after all, the Windows machine didn't come with any programming tools; what a gyp! Can you imagine my disappointment? It wasn't until I discovered Linux and FOSS that I finally stopped going back to the Acorn whenever I felt the urge to hack, and even then it took a while.
I now have an MEng. in Computer Science and Cybernetics; program in Perl, Python, PHP and C/C++ (depending on the task at hand) on a regular (and paid) basis; I understand the tradeoff between fast programs and fast development times. I cannot stand VB; it is a mess. I grew to like Delphi - the teaching language - whilst at uni, but when I can't make it do what I want, I'll go create a command-line utility in C that does it, then hit Object Pascal until I get an equivalent algorithm out of it. To this day, I still use text terminals under Linux on a daily basis, and insist on binding F12 to open a terminal emulator in Gnome. Python's interactive mode is probably the closest thing I've seen in years to good ol' BBC BASIC, but it still doesn't give you fully integrated graphics and sound control - I understand why (portability concerns; device driver issues; the contemporary expectation that programming environments are "just a tool" and should behave like just another window on the desktop), but that doesn't mean I have to like it.
Well its predecessor - the GP32 - existed, sold, and didn't cause the company to get sued into the ground. Just to point out that these people have a track record.
:)
Also, if you don't use WMV or WMA formats at the moment, why does it matter to you personally whether and how the device plays then? Even MP3 is patented. I'm more interested in the claimed Ogg Vorbis and XviD support.
Don't worry about it. I just pre-ordered one (yay!) from FF with no problems - the actual card details are entered on a seperate, SSLed site, which then drops you back to the gp2x site and gives you your order number. They're just covering their backs.
...in terms of media support and homebrew development? The GP2X supports Ogg Vorbis and DivX amongst others, and possibly even XviD (correct me if I'm wrong; I'm sure I read about it somewhere, just can't find a reference on the new site). It's a very tempting piece of hardware.
However, the XGP - comparitively ugly as it may be, if you ask me - has a larger screen and supports OpenGL ES, tempting to me as a developer. But I have no idea whether it's intended to be an open platform; or, if it's not, whether it has decent codec support (WHY are there so few portable ogg players?).
I think the parent was talking about it being a downgrade compared to the original GP32, not the XGP (the "other" console on the link you posted), which is an entirely different, also new handheld. I don't know the details, but the original Gamepark is now split into two companies, each releasing a different product.
I didn't know about said extension, and I for one have never used it, nor know anyone personally who does. Nor can a (very brief, admittedly) stint with Google or mozdev turn up such a thing. I'm not saying it doesn't exist - but if it does, it's not perhaps as commonly used as you think.
I've also suffered from very few (possible none) IE exploits on my machine, but the "family" PC - a winXP box - used to be forever getting hit with spyware, adware, things transparently replacing the home page/search function, and so on and so forth. (Yes, I switched it over to Firefox the best part of a year ago now, but the problems with spy/adware aren't completely gone - largely due to my mum's free game habit and my sister's kazaa addiction.)
You and I know what we're doing with our computers. To the people using the box downstairs in the kitchen, it's just a tool, they don't want to have to think about such things.