Well, he was sitting on it, and I guess no one wanted to move him in case they messed up his hair...
There's only one reason I'd make a DVR...
on
Build Your Own DVR
·
· Score: 1
...and that's the Freedom and openness of a linux-based DVR system. Upgradeable kernel, upgradeable DVR software (including future codecs), upgradeable hardware, and reliable online tech. support.
If you just want something that plays your DVRs for a few years until it hits the end of it's product lifecycle, then yes: there's probably no benefit in a custom-built solution. However, when you factor in those things above, a Linux based DVR starts to look pretty good.
Agreed. I've mentioned this before in previous Trek articles, but I liked Star Trek: TNG for the ethical dilemmas, the hints at mankind's potential, goodness, discovery, and the general sense of something bigger than our own petty modern squabbles over territory or wealth etc.
These recent treks that are all about wars and payback (thinly veiled references to the war on terror etc.) are the complete antithesis of what I felt Star Trek was about.
There have been studies done showing that 4 is the optimal tab size for code. I think it could be standardised easily, at least in coding standards like GNU's. Of course, with in-code settings like VI allows, or IDEs that save their settings in a project file, it's not so much of an issue anyway.
Yes, agreed. But that's a socioeconomic issue, which probably applies to much of the entertainment industry (maybe even most of modern capitalism), rather than a technological one involving computer game design issues.
I'd certainly like to see that problem fixed, but I'm not sure computer game designers will be the ones to do it, unless they stop designing games and apply their problem solving skills to something completely different;)
Revolution isn't always a good thing; it's true. It is sometimes.
However, I think the most appropriate word here is EVOLUTION. We're talking about how the gaming industry improves over time, and whether that should be by rehashing old ideas, or creating new, mutant ideas. That is precisely what evolution is about, and if you know how evolution works, you know precisely why new mutations are so important.
By contrast, revolution is more about starting from scratch with a new approach entirely. If computer gaming became running around outside with a computer on your back and a hud, that might be more revolutionary.
On the other hand, evolution DOES make huge changes in the beginning, as non-viable lifeforms appear, then quickly die. Only the good ones go on to be refined, and that process of refinement is much slower. Still, occasionally a mutation event will still come along, and if it's good, it'll take over.
Maybe the problem with Dvorak is that he just doesn't realise how long evolution takes. So far, the computer industry has been moving pretty fast, considering the history of organic evolution;)
OS-Level scripting is absolutely NOT to be ignored. Amigas did it years ago with ARexx, and it was an incredibly powerful feature. In fact, I would go as far as to say that it's the GUI equivalent of Unix's small-but-pipeable-commands philosophy.
I'm quite surprised that it's not universally supported on Unix machines now. Luckily, KDE at least does support it via DCOP and scripting APIs along with command line apps to access DCOP calls.
To give a few quick examples:
I recently discovered started using KDE's automatic wallpaper cycling for a given directory full of wallpapers. However, some wallpapers wouldn't suit my mood at a certain moment, and some wouldn't look as good on screen as they did when I downloaded them. So I figured I'd add some buttons to the panel: A red X for "Delete Wallpaper", and a forward arrow to switch to the next wallpaper. Implementing that took LESS than a MINUTE, since I just had to open a console, run "dcop", and see that kde exposes two helpful calls:
kdesktop KBackgroundIface changeWallpaper
and
kdesktop KBackgroundIface currentWallpaper
The first command was added directly to the next wallpaper button, and the second was added to a short script that uses it to get the wallpaper name, changes to the next wallpaper, then deletes the old one.
As another example, I have a quick little script that finds my currently playing song in whatever KDE music player I happen to be using via dcop, without the need for specially made command line tools that access the players API, such as xmms provides.
The real power comes when you want to do things like connecting a 3D rendering app to a photo manipulation app, followed by lipsync tool and a final movie encoder.
ARexx was doing things like this years ago, and it's perfectly possible (and implemented!) on Linux today. It's just a shame more people aren't aware of and using it. We're ignoring potential power, as if we all used DOS and continued to claim that Unix command line functionality was pointless and unnecessary. Maybe when we use Unix the way it CAN be used, we'll finally have a killer app that puts the secrecy of windows' proprietary apps to shame.
At the very least, I would ask people not to insult OS X for finally implementing this important feature. They seem to have done it in an innovative GUI-based way, too.
I really feel uneasy if my boss was able to take a copy of my harddrive image and see what I've been working on.
I agree that such things are a valid concern, but this technology isn't meant to solve such problems. That's what block-level encryption is for. I presume you can do that on NetBSD, as well as encrypting your swap space to prevent any data on disk being unencrypted. Not that you'd want to backup your swap space, though;)
Last I know apple is in the market to make money. KDE guys are not.
Sorry, gotta call BS on that.
For one thing, KHTML is saving them money, since it gave Apple a great basis for a browser by which they could (at least partially) unhitch themselves from their direct competitor, who otherwise had them by the nuts on browsing.
Secondly, many computer science projects rely on academia for fundamental algorithms etc., and that generally works just fine.
In IT, just as in science, cooperation works, and competition harms not only the wider IT culture, but the individuals who try to go proprietary. And no, MS didn't get where they by going proprietary, they did that by monopolistic practices which have been ruled illegal in courts of law.
I don't believe he does get all the credit for Konqueror's success.
No, of course he doesn't. The comment by Have Blue said that within the scope of this article it's all Hyatt, though. Which I think, even with his scope qualification, deserved to be clarified a little. You can disagree if you want, but it's better to point out credit where credit is due than to stay silent and allow an article discussion to become one-sided.
Well, let's be honest. He gives stuff to schools so he can encourage the schools to teach MS-specific stuff at the expense of a well-rounded IT education.
Dungeon Siege, of course. Friends of mine where so obsessed with Dungeon Keeper when it first came out that I heard of it all the time, and I keep thinking of it first now.
As for "bashing"... I'm not bashing anyone. I raised a possible explanation for something, which may be wrong. It says right on this page that Microsoft is the publisher, and Microsoft's name was quite blatantly obvious on Dungeon Siege, iirc. Either way, no harm done if I'm wrong.
As for me personally avoiding microsoft-related products, well that's my choice, and it's based on not wanting to contribute to the success of a socially unhelpful organisation. What I said stands on that.
Dungeon Keeper was very short too, and that was also a Microsoft title, IIRC. Maybe there's a pattern here.
Anyway, nice as it looks, I'll be boycotting this MS junk. It's sad to see Bioware getting into bed with MS. Hopefully someone will pickup where they've left off:(
Konqueror still put in place all of the stuff necessary to make this happen. According to his blog, the he's only been working on this since April 12, but Konqueror has been in development for years. That's what we call standing on the shoulders of giants.
Also, I'll be interested to see when Dave/Apple get around to contributing this back to the KDE team.
lots of reasons to write applications in Excel. The best one being that you probably already have it on your machine (no need to purchase a development environment).
Of course, if you choose a decent OS, you can just apt-get install <whatever you REALLY need> instead;)
Another good one being that probably most of your users will have the "platform" to run your application.
They'd better have, because if they don't, they'll have to shell out a lot of cash for it. On the other hand, if you had used Free Software, you'd be able to package that with your app without charge, integrate it more fully, point customers to online support, and ship upgrades as they become available.
What else? How about an insanely good function library, including some amazing graphing tools?
Although, if you go non-proprietary, that stuff would probably be in a library, that you can use directly without all the bloat of an office suite app.
The best part of this news is that, someday, kids will pull these wires out of their toys. I can almost see them ridiculing teachers who claim that, a long time ago, some of the top organisations on the planet took years and millions to build just one of these.
The only relevant question is whether open-source ventures fail any more often than the average IT venture.
Another important question is how likely are Venture Capitalists to "get" Free Software? Can any of them actually tell a good Free Software project from a bad one? Given the nature of Free Software, and the nature I suspect Venture Capitalists have, along with their probable low interest in such things, I truly doubt it.
This is a good example of code that can be improved for documentation and readability, actually. Instead of checking for negatives, which is backwards to normal thinking, you can assume a combination will not work, and then describe the combos that will work:
A comparatively small loop function can check the list:
/* checkPotionCombo
Check a given combination of potions, returning the potion that results.
Returns: the combined potion, or an empty flask if the mixture is invalid. */ function checkPotionCombo(Potion a, Potion b) { /* Ensure arguments are valid */ REQUIRE(isValidPotion(a)); REQUIRE(isValidPotion(b));
Potion result = EMPTY_FLASK;
/* make sure argument order matches the order of our combination lists (lower potion number first) */ a = min(a,b); b = max(a,b);
/* loop through each potion combination */ for (i=0; i<NUM_POTION_COMBOS; ++i) { /* check that the potion combi is filled in properly */ assert(isValidPotion(potionCombos[i].a)); assert(isValidPotion(potionCombos[i].b)); assert(isValidPotion(potionCombos[i].result));
/* check if this combination matches the arguments */ if ((potionCombos[i].a == a) && (potionCombos[i].b == b)) { /* this combination works. Use its result, and stop searching */ result = potionCombos[i].result; break; } }
/* make sure we're not returning junk */ ENSURE(isValidPotion(result));
if the open source software is used and fails then where does the accountability lie?
It's just there: with the people who choose to use it. If they release something as Free Software, there are likely three possible reasons:
The software is good, and they want it to be better
The software is not good, and they want it to be fixed.
The software is great, and they want everyone to have access to it.
In all of these cases, the final responsibility for using that free software in a project lies with those who actually incorporate it into the project. In all of these cases, they can choose an older fork which is known good. And again, in all of these cases, they can test heavily.
Free Software is a social contribution and a development model, but it's not a quality control system, and never will be. Of course, there are probably quality control systems that are Free Software, too;)
Well, he was sitting on it, and I guess no one wanted to move him in case they messed up his hair...
...and that's the Freedom and openness of a linux-based DVR system. Upgradeable kernel, upgradeable DVR software (including future codecs), upgradeable hardware, and reliable online tech. support.
If you just want something that plays your DVRs for a few years until it hits the end of it's product lifecycle, then yes: there's probably no benefit in a custom-built solution. However, when you factor in those things above, a Linux based DVR starts to look pretty good.
Open Source has nothing to do with GNU.
Agreed. I've mentioned this before in previous Trek articles, but I liked Star Trek: TNG for the ethical dilemmas, the hints at mankind's potential, goodness, discovery, and the general sense of something bigger than our own petty modern squabbles over territory or wealth etc. These recent treks that are all about wars and payback (thinly veiled references to the war on terror etc.) are the complete antithesis of what I felt Star Trek was about.
Somehow the thought of an elevator that plays "It's been a long road gettin' from there to here" doesn't sound great for customer satisfaction ;)
There have been studies done showing that 4 is the optimal tab size for code. I think it could be standardised easily, at least in coding standards like GNU's. Of course, with in-code settings like VI allows, or IDEs that save their settings in a project file, it's not so much of an issue anyway.
Yes, agreed. But that's a socioeconomic issue, which probably applies to much of the entertainment industry (maybe even most of modern capitalism), rather than a technological one involving computer game design issues.
I'd certainly like to see that problem fixed, but I'm not sure computer game designers will be the ones to do it, unless they stop designing games and apply their problem solving skills to something completely different ;)
Revolution isn't always a good thing; it's true. It is sometimes.
However, I think the most appropriate word here is EVOLUTION. We're talking about how the gaming industry improves over time, and whether that should be by rehashing old ideas, or creating new, mutant ideas. That is precisely what evolution is about, and if you know how evolution works, you know precisely why new mutations are so important.
By contrast, revolution is more about starting from scratch with a new approach entirely. If computer gaming became running around outside with a computer on your back and a hud, that might be more revolutionary.
On the other hand, evolution DOES make huge changes in the beginning, as non-viable lifeforms appear, then quickly die. Only the good ones go on to be refined, and that process of refinement is much slower. Still, occasionally a mutation event will still come along, and if it's good, it'll take over.
Maybe the problem with Dvorak is that he just doesn't realise how long evolution takes. So far, the computer industry has been moving pretty fast, considering the history of organic evolution ;)
OS-Level scripting is absolutely NOT to be ignored. Amigas did it years ago with ARexx, and it was an incredibly powerful feature. In fact, I would go as far as to say that it's the GUI equivalent of Unix's small-but-pipeable-commands philosophy.
I'm quite surprised that it's not universally supported on Unix machines now. Luckily, KDE at least does support it via DCOP and scripting APIs along with command line apps to access DCOP calls.
To give a few quick examples:
I recently discovered started using KDE's automatic wallpaper cycling for a given directory full of wallpapers. However, some wallpapers wouldn't suit my mood at a certain moment, and some wouldn't look as good on screen as they did when I downloaded them. So I figured I'd add some buttons to the panel: A red X for "Delete Wallpaper", and a forward arrow to switch to the next wallpaper. Implementing that took LESS than a MINUTE, since I just had to open a console, run "dcop", and see that kde exposes two helpful calls:
kdesktop KBackgroundIface changeWallpaper
and kdesktop KBackgroundIface currentWallpaper
The first command was added directly to the next wallpaper button, and the second was added to a short script that uses it to get the wallpaper name, changes to the next wallpaper, then deletes the old one.
As another example, I have a quick little script that finds my currently playing song in whatever KDE music player I happen to be using via dcop, without the need for specially made command line tools that access the players API, such as xmms provides.
The real power comes when you want to do things like connecting a 3D rendering app to a photo manipulation app, followed by lipsync tool and a final movie encoder.
ARexx was doing things like this years ago, and it's perfectly possible (and implemented!) on Linux today. It's just a shame more people aren't aware of and using it. We're ignoring potential power, as if we all used DOS and continued to claim that Unix command line functionality was pointless and unnecessary. Maybe when we use Unix the way it CAN be used, we'll finally have a killer app that puts the secrecy of windows' proprietary apps to shame.
At the very least, I would ask people not to insult OS X for finally implementing this important feature. They seem to have done it in an innovative GUI-based way, too.
Sorry, gotta call BS on that.
For one thing, KHTML is saving them money, since it gave Apple a great basis for a browser by which they could (at least partially) unhitch themselves from their direct competitor, who otherwise had them by the nuts on browsing.
Secondly, many computer science projects rely on academia for fundamental algorithms etc., and that generally works just fine.
In IT, just as in science, cooperation works, and competition harms not only the wider IT culture, but the individuals who try to go proprietary. And no, MS didn't get where they by going proprietary, they did that by monopolistic practices which have been ruled illegal in courts of law.
That's well and good; still doesn't mean that he should get all the credit for Konqueror's success, though.
And if you cared to notice, I have already acknowledged that in this thread.
Well, let's be honest. He gives stuff to schools so he can encourage the schools to teach MS-specific stuff at the expense of a well-rounded IT education.
Dungeon Siege, of course. Friends of mine where so obsessed with Dungeon Keeper when it first came out that I heard of it all the time, and I keep thinking of it first now.
As for "bashing"... I'm not bashing anyone. I raised a possible explanation for something, which may be wrong. It says right on this page that Microsoft is the publisher, and Microsoft's name was quite blatantly obvious on Dungeon Siege, iirc. Either way, no harm done if I'm wrong.
As for me personally avoiding microsoft-related products, well that's my choice, and it's based on not wanting to contribute to the success of a socially unhelpful organisation. What I said stands on that.
All our base are bemoaning you.
Heh... I can't even be bothered with my own blog lately. A release note I could have handled, but a blog is a bit much.
But yes, I assumed the code was available somewhere.
Dungeon Keeper was very short too, and that was also a Microsoft title, IIRC. Maybe there's a pattern here.
Anyway, nice as it looks, I'll be boycotting this MS junk. It's sad to see Bioware getting into bed with MS. Hopefully someone will pickup where they've left off :(
Konqueror still put in place all of the stuff necessary to make this happen. According to his blog, the he's only been working on this since April 12, but Konqueror has been in development for years. That's what we call standing on the shoulders of giants.
Also, I'll be interested to see when Dave/Apple get around to contributing this back to the KDE team.
The best part of this news is that, someday, kids will pull these wires out of their toys. I can almost see them ridiculing teachers who claim that, a long time ago, some of the top organisations on the planet took years and millions to build just one of these.
This is a good example of code that can be improved for documentation and readability, actually. Instead of checking for negatives, which is backwards to normal thinking, you can assume a combination will not work, and then describe the combos that will work:
/* Ensure arguments are valid */
/* make sure argument order matches the order
/* loop through each potion combination */
/* check that the potion combi is filled in
/* check if this combination matches the
/* this combination works. Use its
/* make sure we're not returning junk */
Most of your code would look like this then:
PotionCombo potionCombos[] = {
{ WATER, SOIL, MUD }
{ WATER, BEER, CHEAP_BEER }
};
A comparatively small loop function can check the list:
/* checkPotionCombo
Check a given combination of potions,
returning the potion that results.
Returns: the combined potion, or an empty
flask if the mixture is invalid.
*/
function checkPotionCombo(Potion a, Potion b) {
REQUIRE(isValidPotion(a));
REQUIRE(isValidPotion(b));
Potion result = EMPTY_FLASK;
of our combination lists (lower potion
number first) */
a = min(a,b);
b = max(a,b);
for (i=0; i<NUM_POTION_COMBOS; ++i) {
properly */
assert(isValidPotion(potionCombos[i].a));
assert(isValidPotion(potionCombos[i].b));
assert(isValidPotion(potionCombos[i].result));
arguments
*/
if ((potionCombos[i].a == a)
&& (potionCombos[i].b == b)) {
result, and stop searching */
result = potionCombos[i].result;
break;
}
}
ENSURE(isValidPotion(result));
return result;
}
It's just there: with the people who choose to use it. If they release something as Free Software, there are likely three possible reasons:
In all of these cases, the final responsibility for using that free software in a project lies with those who actually incorporate it into the project. In all of these cases, they can choose an older fork which is known good. And again, in all of these cases, they can test heavily.
Free Software is a social contribution and a development model, but it's not a quality control system, and never will be. Of course, there are probably quality control systems that are Free Software, too ;)