Are there really any examples of "homebrew" games for modern systems? Being as complex as they are to program, I don't really see why anyone would bother homebrewing a game on the 360 when they can produce the exact same software for the PC. (Much quicker and easier, too.)
Try this for an example for instance. Sure, many of the titles are ports of existing software to Xbox. But as with all things that involve some hackery, there's never need for question why. You'll always get the ultimate answer: because you can. And quite frankly, that's all the reasoning you need. Oh, and speaking about Xbox. It's pretty much a PC running stripped down Windows and is programmed accordingly (after you manage to get your own, unsigned code to run on it, but as we all know, that's been possible for longer time than anyone remembers).
The Xbox360 HD is basically a standard SATA laptop HD covered with a fancy casing. If a modchip for the system is eventually developed, I'm pretty damn sure that compared to that feat, it's a piece of cake to build an adapter that lets you use any hard disk with a SATA connector with Xbox360. Sure you can't fit a 500GB 3.5" drive inside the case but who cares if it must sit next to the case if it works?
First, I must comment the article. Question goes What little known command performs just the right function for you? I hope all sane people here (haha) would answer "None". There's no command that does just the right function since there's no one The Function. It depends on the situation what the function is. And in that case, per Unix philosophy, where one tool does one simple job, but does it well, you should choose the tool accordingly.
Enough of that. If you really must name something, then, in my opinion, there's one gizmo above others. And that is
perl
Perl one-liners is a damn powerful concept when you get it. Say one of your boxen switches IP address. You want to replace all references in files under/etc to this new IP address. First you might think searching all the files under/etc with find(1), then passing the list of files to grep(1) and then manually editing the places where the old IP address was found with your $EDITOR. That's fine and will get the job done and all but what if you could just edit the files in place? With perl, you can.
perl -pne's/oldip/newip/g' -i `find/etc -type f`
and you're done (better be extra careful with commands like that for obvious reasons!). Of course you're able to do the same thing with other tools too, but I don't think it could be much easier than that. And naturally you're not just limited to simple search and replace of text, you have the full power of Perl (and CPAN!) at your disposal.
Besides being my number one choice for creating complex scripts and small applications, Perl has very special place in my command line toolbox just next to the old friends such as grep(1), cut(1), wc(1), etc. and a huge pile of pipes:)
You did know that Gmail is still in beta invite-only mode, didn't you? When something is beta, it's not ready and it's being constantly under development, don't you think? So Gmail "didn't came out almost 2 years ago" and it won't have radical flood of features within next 6 months. Small, gradual improvements instead, just like during those last 2 years.
Not that I don't like Gmail, it's just that fanboism like that is quite irritating.
RPM uses both MD5 and SHA1, the chances of finding a collision that satisfies both hashes is small, even if both MD5 and SHA1 are compromised since the hash the data differently.
Also SSL 3.0 and TLS 1.0 uses this kind of combination of different hash functions. You're still relatively secure even if one of the two functions would be completely compromised. Simple and efficient, I like it.
We're in the same boat. My boss decided to get me and the other folks at my department Nokia 9500s so that we could come to rescue when it's needed, anytime, anywhere (almost). Well I agree that Nokia 9500 is a huge brick. But the boss already ordered the phones. Luckily the nice manager of sales department was in need of a new 9500 too, so I gave mine to him and he ordered a Nokia 9300 for me. What a sweet deal it was! It's basically the same thing as 9500. It runs the same OS minus the WiFi (have no need) and camera (have even less need! Besides the 9500 camera is utter crap anyway) bits. All software is compatible. But it's so much smaller and slimmer! About the size of a regular GSM phone from 4-5 years ago. You can happily carry that in shirt pocket (not a chance with 9500). Due to its compact size, the keyboard is slightly smaller than the one in 9500, but that's not a problem for me at least. The display is also a bit smaller, but the resolution is the same as in 9500. No problems reading mail with mutt etc. in Putty session. Highly recommended device. Especially if you find Nokia 9500 suitable if it only was smaller. Namely this thing is exactly that! Maybe missing WiFi is a show stopper for some people, but if you can handle that, then there's no excuse not to get a Nokia 9300 to handle this kind of job.
Well can't they just continue using GPLv2? It's not like the licensing of all GPLed software in the world is automatically upgraded at the second FSF releases GPLv3. Eg. if, for some odd reason, Linus decides to go with GPLv3 with Linux, you can continue using and fork the latest Linux that was released under GPLv2 (this is also the reason why I doubt very few large scale GPLv2 projects will change the licensing to GPLv3 given these anti-corporate clauses are really left in the final version - you have to remember GPLv3 is only in the drafting stage at the moment).
Average member of Slashdot crowd isn't fully proficient in commenting flight safety. Your local air line representative is. So why don't you pick up your phone and make a call and have your question answered in no less than 30 seconds by a professional?
Uh I'd say that you hardly can draw any conclusions from the fact that some IBM product happens to use Opera and that now some other product is going to use Firefox. They're pretty big company, you know. AIX ships with Netscape Communicator 4. OS/2 ships with its own in-house made browser, whatever it's called (probably just IBM Web Browser for OS/2 or something, forgot it now, but it's supported nevertheless). I'm sure they've got some Windows-only stuff that depend on Internet Explorer. So you can safely throw in Opera and now Firefox too, but it doesn't mean they're shiting their focus from product A to product B. They're all needed in different places of the huge IBM ecosystem (or at least that's what they think).
Of course I didn't RTFA, but how do they plan to handle the inevitable updating of PC games? Read-only medium works reasonably well with console games since the developers know exactly with what kind of hardware the consumers are going to play the game so they can optimize and overcome the known quirks of the platform. On PCs however, there's infinite combination of processors, video cards and other peripherals. While things like OpenGL and DirectX deal with the majority of technical problems that existed in gaming in DOS era, you still can't get it always right. So besides game logic etc. updates, you often need to release purely technical compatibility patches in order to make your product available with enjoyable experience to as many consumers as possible. How's this supposed to be done if PC games are distributed on read-only media, too?
I hate to disappoint you, but Linux 2.6 used in RedHat 4 enterprise distributions hardly makes it a major milestone in the Linux server arena. Enterprise Linux distributions with Linux 2.6 kernel is not exactly a ground breaking thing. SUSE LINUX Enterprise 9 featuring Linux 2.6 was released many months ago. Also the 2.4 kernel used in the 3 series of RedHat enterprise distributions isn't quite vanilla 2.4. It contains already many, many features backported from Linux 2.6.
I'd like to see whatever it is that would get one into the Darwin Awards using the Shuffle. Well, this is too easy. Despite the warnings, you eat it of course.
Here in Finland we've had these kind of id cards since 2000 or so. The novel idea is that that the authorities issue one for you and then you can use it when you need to prove who you are when doing business with the authorities from home. Great in theory since you can use web service from your home's comfort while previously you'd had to go there and have some other official identity with you, eg. passport. Well this thing pretty much flopped. Very rare service support it (though my company offers a service that supports it) and even fewer have card readers at home. It's a chicken and egg problem, really, combined with unfamiliar for the common people technology and concepts. Nowadays, when you need secure e-identification, many use the identification services offered by banks. Finnish banks are pioneers in e-banking and their systems are very established and generally trusted. So they've found a new business opportunity in offering their authentication and identification technology to 3rd parties who need their customers identified and are willing to out-source the operation. And this is something about everyone can use since on-line banking is so so 1996 that everyone does it by now. And to authenticate you don't need any extra computer stuff or passwords, just the code sheet your bank sent you. I believe electronic ID card is much more popular in Estonia. I don't know why, but they've been using it almost as long as Finland.
And to all American who are wondering the privacy effects. It's difficult for us to see your point. For us national id cards are no privacy threat at all. This is because the ids are mainly used when dealing with authorities, banks, etc. who one can trust (authorities) or whose interest is that their customer's privacy isn't compromised so they do their best to ensure that (banks, etc.). And why do we trust the authorities? Well our rulers don't have the habit to piss off the people by doing really things to us. And if something happened either intentionally or accidentally, they'd get caught very soon. According to Transparency International, Finland has been the least corrupted country on the planet for five consecutive years now. But it wasn't worse before, but the mutual trust and respect between governance and the people have been there since the 1917 independence.
Human is an animal, thank you very much. Biped, primate mammal, in fact. They may've created a new hybrid breed which involved human species, and that's bad thing, though.
So you're willing to experiment with a new system. Then why not install all of the free BSD's and use each for a few weeks and after that decide which one to keep, if any.
Nice reading there, CowboyNeal
on
Is IRC All Bad?
·
· Score: 5, Insightful
His conclusions are quite alarming, suggesting that 99.9% of IRC usage is illegal
From TFA: Based on those keywords being monitored, 99.9% of IRC traffic to the top 60 channels is "illegal".
Clearly, (all) IRC usage != IRC traffic to the top 60 channels.
Things like form validate is WRONG - the backend should do that, not the client. No, client form validation is definitely GOOD. With proper client side form validation in normal cases you can prevent unnecessary requests (those with invalid input) to the server. This saves both user's time and your bandwidth bill. Of course, validation MUST also performed also on the server side (client may not support JavaScript for a reason or another or client may maliciously by-pass the JavaScript validation). You can't assume anything about client's input but if client's playing nice, JavaScript form validation is a win-win situation. Of course you shouldn't be coding client-side and server-side checks by hand but instead use framework such as Struts Validator, which generates the client side JavaScript and performs server side validation from the common validation rule set.
If you would've been around in Usenet in early 90's, would you've told the same thing to this lunatic Linus Torvalds who wants to build an Unix-like operating system for PC from the scratch? If he's so talented, why is he wasting resources instead of joining the GNU project and help them to get the free Unix running or BSD camp who actually had free, working Unix at the time? Well he decided to do his own thing because he was a stupid, stubborn young and naive college student. What a jerk, nothing useful ever came out of it.
Slashdot Mirror
Are there really any examples of "homebrew" games for modern systems? Being as complex as they are to program, I don't really see why anyone would bother homebrewing a game on the 360 when they can produce the exact same software for the PC. (Much quicker and easier, too.)
Try this for an example for instance. Sure, many of the titles are ports of existing software to Xbox. But as with all things that involve some hackery, there's never need for question why. You'll always get the ultimate answer: because you can. And quite frankly, that's all the reasoning you need. Oh, and speaking about Xbox. It's pretty much a PC running stripped down Windows and is programmed accordingly (after you manage to get your own, unsigned code to run on it, but as we all know, that's been possible for longer time than anyone remembers).
There're no Windows call emulation code in Mac IE. Like Office for Mac, it's written from the scratch for (the old) Mac OS.
The Xbox360 HD is basically a standard SATA laptop HD covered with a fancy casing. If a modchip for the system is eventually developed, I'm pretty damn sure that compared to that feat, it's a piece of cake to build an adapter that lets you use any hard disk with a SATA connector with Xbox360. Sure you can't fit a 500GB 3.5" drive inside the case but who cares if it must sit next to the case if it works?
First, I must comment the article. Question goes What little known command performs just the right function for you? I hope all sane people here (haha) would answer "None". There's no command that does just the right function since there's no one The Function. It depends on the situation what the function is. And in that case, per Unix philosophy, where one tool does one simple job, but does it well, you should choose the tool accordingly.
/etc to this new IP address. First you might think searching all the files under /etc with find(1), then passing the list of files to grep(1) and then manually editing the places where the old IP address was found with your $EDITOR. That's fine and will get the job done and all but what if you could just edit the files in place? With perl, you can.
/etc -type f`
:)
Enough of that. If you really must name something, then, in my opinion, there's one gizmo above others. And that is
perl
Perl one-liners is a damn powerful concept when you get it. Say one of your boxen switches IP address. You want to replace all references in files under
perl -pne's/oldip/newip/g' -i `find
and you're done (better be extra careful with commands like that for obvious reasons!). Of course you're able to do the same thing with other tools too, but I don't think it could be much easier than that. And naturally you're not just limited to simple search and replace of text, you have the full power of Perl (and CPAN!) at your disposal.
Besides being my number one choice for creating complex scripts and small applications, Perl has very special place in my command line toolbox just next to the old friends such as grep(1), cut(1), wc(1), etc. and a huge pile of pipes
You did know that Gmail is still in beta invite-only mode, didn't you? When something is beta, it's not ready and it's being constantly under development, don't you think? So Gmail "didn't came out almost 2 years ago" and it won't have radical flood of features within next 6 months. Small, gradual improvements instead, just like during those last 2 years.
Not that I don't like Gmail, it's just that fanboism like that is quite irritating.
RPM uses both MD5 and SHA1, the chances of finding a collision that satisfies both hashes is small, even if both MD5 and SHA1 are compromised since the hash the data differently.
Also SSL 3.0 and TLS 1.0 uses this kind of combination of different hash functions. You're still relatively secure even if one of the two functions would be completely compromised. Simple and efficient, I like it.
We're in the same boat. My boss decided to get me and the other folks at my department Nokia 9500s so that we could come to rescue when it's needed, anytime, anywhere (almost). Well I agree that Nokia 9500 is a huge brick. But the boss already ordered the phones. Luckily the nice manager of sales department was in need of a new 9500 too, so I gave mine to him and he ordered a Nokia 9300 for me. What a sweet deal it was! It's basically the same thing as 9500. It runs the same OS minus the WiFi (have no need) and camera (have even less need! Besides the 9500 camera is utter crap anyway) bits. All software is compatible. But it's so much smaller and slimmer! About the size of a regular GSM phone from 4-5 years ago. You can happily carry that in shirt pocket (not a chance with 9500). Due to its compact size, the keyboard is slightly smaller than the one in 9500, but that's not a problem for me at least. The display is also a bit smaller, but the resolution is the same as in 9500. No problems reading mail with mutt etc. in Putty session. Highly recommended device. Especially if you find Nokia 9500 suitable if it only was smaller. Namely this thing is exactly that! Maybe missing WiFi is a show stopper for some people, but if you can handle that, then there's no excuse not to get a Nokia 9300 to handle this kind of job.
Well can't they just continue using GPLv2? It's not like the licensing of all GPLed software in the world is automatically upgraded at the second FSF releases GPLv3. Eg. if, for some odd reason, Linus decides to go with GPLv3 with Linux, you can continue using and fork the latest Linux that was released under GPLv2 (this is also the reason why I doubt very few large scale GPLv2 projects will change the licensing to GPLv3 given these anti-corporate clauses are really left in the final version - you have to remember GPLv3 is only in the drafting stage at the moment).
Average member of Slashdot crowd isn't fully proficient in commenting flight safety. Your local air line representative is. So why don't you pick up your phone and make a call and have your question answered in no less than 30 seconds by a professional?
Uh I'd say that you hardly can draw any conclusions from the fact that some IBM product happens to use Opera and that now some other product is going to use Firefox. They're pretty big company, you know. AIX ships with Netscape Communicator 4. OS/2 ships with its own in-house made browser, whatever it's called (probably just IBM Web Browser for OS/2 or something, forgot it now, but it's supported nevertheless). I'm sure they've got some Windows-only stuff that depend on Internet Explorer. So you can safely throw in Opera and now Firefox too, but it doesn't mean they're shiting their focus from product A to product B. They're all needed in different places of the huge IBM ecosystem (or at least that's what they think).
Of course I didn't RTFA, but how do they plan to handle the inevitable updating of PC games? Read-only medium works reasonably well with console games since the developers know exactly with what kind of hardware the consumers are going to play the game so they can optimize and overcome the known quirks of the platform. On PCs however, there's infinite combination of processors, video cards and other peripherals. While things like OpenGL and DirectX deal with the majority of technical problems that existed in gaming in DOS era, you still can't get it always right. So besides game logic etc. updates, you often need to release purely technical compatibility patches in order to make your product available with enjoyable experience to as many consumers as possible. How's this supposed to be done if PC games are distributed on read-only media, too?
I hate to disappoint you, but Linux 2.6 used in RedHat 4 enterprise distributions hardly makes it a major milestone in the Linux server arena. Enterprise Linux distributions with Linux 2.6 kernel is not exactly a ground breaking thing. SUSE LINUX Enterprise 9 featuring Linux 2.6 was released many months ago. Also the 2.4 kernel used in the 3 series of RedHat enterprise distributions isn't quite vanilla 2.4. It contains already many, many features backported from Linux 2.6.
I'd like to see whatever it is that would get one into the Darwin Awards using the Shuffle.
Well, this is too easy. Despite the warnings, you eat it of course.
Here in Finland we've had these kind of id cards since 2000 or so. The novel idea is that that the authorities issue one for you and then you can use it when you need to prove who you are when doing business with the authorities from home. Great in theory since you can use web service from your home's comfort while previously you'd had to go there and have some other official identity with you, eg. passport. Well this thing pretty much flopped. Very rare service support it (though my company offers a service that supports it) and even fewer have card readers at home. It's a chicken and egg problem, really, combined with unfamiliar for the common people technology and concepts. Nowadays, when you need secure e-identification, many use the identification services offered by banks. Finnish banks are pioneers in e-banking and their systems are very established and generally trusted. So they've found a new business opportunity in offering their authentication and identification technology to 3rd parties who need their customers identified and are willing to out-source the operation. And this is something about everyone can use since on-line banking is so so 1996 that everyone does it by now. And to authenticate you don't need any extra computer stuff or passwords, just the code sheet your bank sent you. I believe electronic ID card is much more popular in Estonia. I don't know why, but they've been using it almost as long as Finland.
And to all American who are wondering the privacy effects. It's difficult for us to see your point. For us national id cards are no privacy threat at all. This is because the ids are mainly used when dealing with authorities, banks, etc. who one can trust (authorities) or whose interest is that their customer's privacy isn't compromised so they do their best to ensure that (banks, etc.). And why do we trust the authorities? Well our rulers don't have the habit to piss off the people by doing really things to us. And if something happened either intentionally or accidentally, they'd get caught very soon. According to Transparency International, Finland has been the least corrupted country on the planet for five consecutive years now. But it wasn't worse before, but the mutual trust and respect between governance and the people have been there since the 1917 independence.
Human is an animal, thank you very much. Biped, primate mammal, in fact. They may've created a new hybrid breed which involved human species, and that's bad thing, though.
So you're willing to experiment with a new system. Then why not install all of the free BSD's and use each for a few weeks and after that decide which one to keep, if any.
His conclusions are quite alarming, suggesting that 99.9% of IRC usage is illegal
From TFA: Based on those keywords being monitored, 99.9% of IRC traffic to the top 60 channels is "illegal".
Clearly, (all) IRC usage != IRC traffic to the top 60 channels.
I can't bear this! I have to wait before I'll be able to play Halo 2 while shuffling the iPod playlist and watching some great movie on DVD and, of course, having a critical business conversation while driving down the freeway. So unfair!
Andrew Tanenbaum - Linus Torvalds TEACHER!
Not really. Andrew Tanenbaum was not Linus' teacher. Linus studied in Finland and Tanenbaum is teaching in The Netherlands.
Why don't you switch your financial vendors then?
Things like form validate is WRONG - the backend should do that, not the client.
No, client form validation is definitely GOOD. With proper client side form validation in normal cases you can prevent unnecessary requests (those with invalid input) to the server. This saves both user's time and your bandwidth bill. Of course, validation MUST also performed also on the server side (client may not support JavaScript for a reason or another or client may maliciously by-pass the JavaScript validation). You can't assume anything about client's input but if client's playing nice, JavaScript form validation is a win-win situation. Of course you shouldn't be coding client-side and server-side checks by hand but instead use framework such as Struts Validator, which generates the client side JavaScript and performs server side validation from the common validation rule set.
Of course, for me all my spam seems to be about rolexes.
Well how about that. Lucky you. To me they only offer replicas!
...but who would believe those dirty Russians so let's just call this a revelation today. Reuters aricle from the Dec 10th.
Pro Hockey exists just fine without the NHL. About every moderately major European country runs a pro league or two.
If you would've been around in Usenet in early 90's, would you've told the same thing to this lunatic Linus Torvalds who wants to build an Unix-like operating system for PC from the scratch? If he's so talented, why is he wasting resources instead of joining the GNU project and help them to get the free Unix running or BSD camp who actually had free, working Unix at the time? Well he decided to do his own thing because he was a stupid, stubborn young and naive college student. What a jerk, nothing useful ever came out of it.