An open message to the Gnome Devs:
We don't want a new interface! We are happy with our crusty old UI! Don't change it to attract new users, or to imitate Apple or Microsoft's UI's. We use X-Windows and/or Gnome because it is not like either of those platforms. You've already lost the desktop war; don't lose your user base as well through stupid changes.
P.S. You don't need to revamp the start menu with each release; we're happy with it as it is as well.
Rather than buying a book on programming for your son, you might want to start him with something real-world that he can make tangible changes with. At stores like Radio Shack and MicroCenter, they sell electronics kits featuring an Arduino microcontroller board. These things are *seriously* fun to play with because its so simple to write code for them. The language you program them in is actually C/C++, but the libraries provided make the C++ look more like javascript. There is a rather large community surrounding the platform, and a whole bunch of 3rd party add-on kits for making them do nifty things.
I think the most important thing at your son's age is for him to be able to write a small fragment of code & see its effect. Something as basic and accessible as an Arduino is perfect for this type of experimentation. To link you to a few resources, the main arduino site is http://arduino.cc./ You can find examples of some of the cool add-ons at http://sparkfun.com/
You might even have some fun with one of these things yourself!
I find this kind of interesting... While I haven't yet played with Android yet (or for that matter Windows on a netbook), this does seem to be an interesting development. I would *really* like to see a performance comparison between Android and Windows on the same netbook; both from a speed and resource consumption standpoint.
Overall, I really like the idea of Android, but think the platform is still too new for anyone to really pay it any serious attention. What really needs to happen is for cell phone manufacturers to have a compelling reason to use it on their cell phones.
That being said, I think Android is going to slowly whither away as a technological footnote over the next several years.
I'm a C++ developer, and I'm mixed on this decision... On one hand, memcpy is a function that you can really hurt yourself with. On the other, it maps to extremely fast assembly that most processors can perform very quickly. There is a time & a place for everything. I think that a memcpy inside a class' constructor or assignment functions is perfectly acceptable, yet doing a memcpy(&destclass, &fromclass, sizeof(destclass)) is fundamentally dumb for more reasons than I care to illucidate (read one of Stroudstrup's or Meyer's books on C++ if you want to know). Doing something like that *really* demonstrates that you don't know the language.
I guess Microsoft is trying to get people that don't understand C++ to program better in the language. IMHO, this will not solve fundamental problems with people programming C++, just cause them to learn the language slower by not having an experience working through a bastard of a bug. I think the world (and not just MS) needs to realize that writing a piece of complex software is difficult. Bugs like an errant memcpy of a subclass into a baseclass instance are *very* easy bugs to solve if you're looking for them. Memory overwrites are easy to detect if you are looking for them. Bad pointers are easy to detect if you're looking for them.
Such problems will always exist in software. I've found a fair number in my own code. What we *really* need to do is train a better caliber of programmer.
OTOH, Microsoft seems hell-bent on trying to make writing software easy to do
A Black Swan is an event that is highly improbably, but statistically probable.
Yes, it is possible for a drive in a RAID 5 array to become absolutely inoperable, and for one of the other drives to have a read failure at the same time. This is highly unlikely though, and is not the Black Swan. The math use to calculate the likelihood of these two events occurring at the same time is faulty. The MTBF metric for hard drives is measured in 'soft failures'; this is very different from a 'hard failure'.
The difference between the two types of failures is that a soft failure, while a serious error, is something that the controlling operating system can work around if it detects it. It is extremely unlikely that a hard drive will exhibit a hard failure without having several soft failures first. It is even more unlikely that two drives in the same array will exhibit a hard failure within the length of time it takes to rebuild the array. In my experience, it is more likely that the software controlling the array will run into a bug rebuilding the array. I've seen this with several consumer-grade RAID controllers.
The true Black Swan is when a disk in the array catches fire, or does something equally as destructive to the entire array.
To echo other people's points, RAID increases availability, but only an off-site backup solves the data retention problem.
This is all great advice. The parts about not being defensive about code you've written are spot-on. I would add the following to the list:
Invest time in making your tool-chain work for you. I've been a professional developer for close to ten years, and tricks that I spent a day figuring out when I was a newbie *still* save me a lot of time. I don't care what environment you're coding in, but having a tool that cross-indexes the source base your working in, and allows you to (in your editor) immediately jump to a different function will save you hours. All IDE's will do this with a small amount of config tweaking. Additionally, emacs & vim are very capable at this once you learn the black art of configuring them.
Recognize when you're doing something tedious. Usually when something is a repetitive drag, you'll save time writing a script to do the repetitive work. It can be a crappy throw-away script... Don't make it work correctly... Just make it good enough that you can hand-edit the output and save yourself time. Finally, save that script somewhere so that you can hack it later if you need to.
I'm going to re-emphasize mr_mischief's point of using a revision control system. Using a revision control system is kinda like always having the ability to save your progress in a video game. An RCS allows you to go back and see what you did that f*ed up the code. I will add that it really helps to have a graphical diff program that works w/ you version control system. IDE's usually provide a graphical diff that understand most version control systems, but find a good one; it will save you hours over time.
I have no idea of what environment you're going to be coding in, but you would do well to learn the basics of editing text with VI... There will be a point that you're on some random system without your IDE... VI is usually available on any system, or easily installed. This again, will save you hours. (Full Disclosure: I use VIM for development for this very reason)
Do your development from the command prompt. Once you learn how to do everything from the prompt, you can script the common stuff.
When someone asks you how long something will take, come up with an honest estimate of the amount of time it will take, and then multiply it by two. It's better to say things will take a while than to be late on a project.
Prototype your code in a high-level language like perl or python, then port it to the language it needs to be written in. It saves you writing code that has stupid bugs in it. You get to write the code w/o dealing with the ugly low-level stuff.
To add to the previous point, pick a prototyping language that you have enough knowledge of to translate your code into the end-result language easily. I would advice against picking a prototyping language like haskell or lisp if you're delivering code in C/C++/C#
Personally, over the past 10+ years of using Linux, I've stuck with either ext2 or ext3. They just work. They're the most commonly used filesystems in Linux, and the tools for recovering your data are the best of any filesystems available under Linux. This is because kernel developers use these filesystems on their crash boxes.
For me to pick a filesystem, I need to know that my data won't be lost. I use a computer for way too much... I'll trade performance for stability when it comes to irreplacable data.
That being said, I've been seeing some interesting things regarding ext4, tux3 and hammer. At least hammer & tux3 will offer you what you want, but neither are past beta stage. My advice is to stick w/ ext2/3 until either (1) ext4 has the features that you need or (2) that the LKML guys start using tux3 or hammer on their crash boxes.
Also, I'm not sure if you're thinking of 'file system compression' as an automatic defrag or of it as true file compression. If it's the former, there are defrag tools that you can run; if it's actual file compression to save space, you are wasting CPU cycles by trying to compress data at the FS level on your MythTV box... Try compressing an mpeg movie with gzip, you'll save maybe 1%. Far better to stick to ext2 for speed or ext3 for data integrity.
It's not a great joke, but it illustrates that in general people in urban areas around the world feel the same way as the Japanese. I've been an urbanite for quite a bit of my life, and while I think street view in kind of creepy, I don't feel the same way as this Japanese guy. Street-view is just way too useful to be against it.
If you're doing simple Key,Record storing, try GDBM (or one of its analogs: DBM, NDBM). IIRC, it's included as part of glibc. The interface for it is analogous to that of a hash table... In fact there's even native Perl support for tying hash tables to GDBM.
If that doesn't satisfy your need, take a look at Berkley DB. It offers a more sophisticated interface than DBM.
Ok, it may be news to all of you, but Ingo Molnar has been working on a schedular that
incorporates most of Con's ideas. It's called the 'Completely Fair Scheduler' (CFS), and its
slated to be released in the 2.6.23 kernel.
If you'd like to read a bit about it and see some benchmarks comparing it to Con's SD scheduler,
there's some very good coverage of it all over at kerneltrap.org
As for people calling for a fork of the Kernel, they obviously don't understand the Kernel development process, or how many forks currently exist.
I believe the Korn and Bash shell are both examples of prior art here... The Korn shell was in existance long before this patent application, and I believe bash has been around as long as well.
I can't wait for them to GPL their implementation. Hopefully there will be enough software in the Tivo that gets licesed under GPLv3 to put these assholes out of business.
As a current Speakeasy subscriber, I am very worried about what the changes will be made to both the terms of service and data monitoring/privacy policies. Also, what impact will being owned by a public company have on policies?
If anyone from Speakeasy is able to thoughtfully answer these concerns, I'd like to know the answers. I have to say I am very disappointed in this deal... Best Buy is not a company I like to do business with. The only way that this deal would have been worse is if Speakeasy pimped themselves to Starbucks.
There is a reason why i rip everything gnome & kde related out of a linux distro after an install... the UI is too much like windows.
I still use fvwm1 (with all of its quirks/bugs) because it gets rid of some of the *basic* usability issues that gnome and kde fail to resolve.
To list a couple:
Why, on an empty desktop, should someone need to click a button to bring up a menu of the most useful things that they can do with the computer?
Why is the close button for windows next to the minimize and maximize buttons? I can't tell you the number of times I clicked on the wrong button and said 'damnit'
why do i need to suck the entire gnome (applies to kde/qt too) environment into a project in order to either render html _or_ print
Why are both the gnome and kde developers more interested in adding features to their 'desktop environment' than fixing the basic problems that are causing them to work around X windows?' HINT: read Keith Packards blog
I think my point is that the gnome and kde projects are not so much about innovating as keeping up with microsoft... We need to create a community devoted to the idea of seeing what Redmond does and saying 'hey, thats interesting, but I can do that better'
This is what the kernel community does constantly... Linus is the gatekeeper, and he is right to critisize... When was the last time you totally changed the internal architecter of a subsystem of your project because you were wrong? For Linus it was the 2.4 MM (mid release cycle)/p?
A couple of years ago I had to create a configuration system for FreeBSD systems in a data center... What I ended up using was a really crappy Perl module called PerlVision to do it (I was basing the code on a config system someone else wrote for some other systems). Anyway, it was pretty painless to do. You might consider writing the UI using a scripting language like perl or python that expose the ncurses bindings and use that to start any back-end processing that needs to happen.
Also, as a design point, you might consider saving the configuration in a flat file that the backend reads. That way you can separate the UI development and testing completely from the actual product... If the need ever arises to create a fancier UI, you'll be able to then do it fairly painlessly.
I've personally made it about 20 hours into the story (including quite a bit of that time spent mindlessly leveling up:), and I have to say that I am really enjoying this game. While there are some things about the game that I could criticize, overall I think that this is one of the finest Final Fantasy games that I've played (and I've played all but XI and the Japanese only releases for the NES).
In terms of story, things do start off a bit choppy and the gambit system takes a while to get used to, but as you settle into the game you really start to have fun. You start to realize that your job in combat is to give general direction to the party, rather than direct every action of every character; this leads to some rewarding battles in which you just watch your characters kick ass on their own. In some ways, I think that this is somewhat better than with previous FF's, in that you don't just stupidly hold down the 'action confirm' button after setting up the cursor to always go to the last selected action.
Up until this game, I would have said that my favorite Final Fantasy would have been FF8, but I'm not so sure of that anymore. Like FF8, this one strives to make all of the various RPG elements (leveling, weapons upgrades and various magical abilities) somewhat believable. The fact that combat takes place in the same environment as the rest of the game play really adds an immersive and seemless quality to the game... A very welcome change.
As for the things that I don't like; there are not many... First and foremost would probably be that the license grid system is somewhat difficult to manage. Unlike other FF's, in order to use anything that you've bought (weapons, armor, spells, etc.), you must also have unlocked the license for that piece of equipment or ability; this leads you to sometimes sit in a weapons shop jumping back and forth between each character's license grid (to see whether its worth buying the weapon now) and the shop's merchandise list. Another thing that I've found to be somewhat annoying about the license grid is that it's really a lot of leveling up to get to the point where you've started to unlock the abilities that you really need, and oft times you have to unlock a bunch of abilities that you really don't care to unlock to get to the ones that you want. A good example of this is that you have to unlock a bunch of healing bonuses to level up the strength and HP of a character that you're trying to turn into a physical fighter. This doesn't make a whole lot of sense to me.
All and all though, a very lovingly crafted game... I might not give it a perfect 10/10, but its pretty close.
I think everyone here at Slashdot recognizes the dangers that these new DRM-infested devices are introducing into modern culture, and I think we can all agree that we would prefer companies to stop producing products that restrict our freedom.
Imagine what would happen if a company produced a portable MP3 and video player, similar to the Zune, that had P2P WiFi-connectivity, a BitTorrent client and possibly a scaled-down version of the Democracy Player . This might just cause the RIAA and MPAA to lose the ability to monitor file sharing and make it impossible to stop (unless the RIAA hires a bunch of thugs to sit in every subway car and bus across the country).
I call on us to figure out how to produce such a device. We need to send a message to companies like Apple, Microsoft and Sony that we will not accept devices broken by DRM.
Is anyone out there interested in helping to start a project to build and open-source piece of hardware to accomplish this?
Slashdot Mirror
...as Microsoft patches the shellshock vulnerability in the bash interpreter underlying all of .net :P
Seriously, kids that age should be playing with other kids, not having their parents helicopter over them with a digital tether.
A few releases before I switched to Mint.
An open message to the Gnome Devs: We don't want a new interface! We are happy with our crusty old UI! Don't change it to attract new users, or to imitate Apple or Microsoft's UI's. We use X-Windows and/or Gnome because it is not like either of those platforms. You've already lost the desktop war; don't lose your user base as well through stupid changes. P.S. You don't need to revamp the start menu with each release; we're happy with it as it is as well.
Linux *is* Unix.
I think the most important thing at your son's age is for him to be able to write a small fragment of code & see its effect. Something as basic and accessible as an Arduino is perfect for this type of experimentation. To link you to a few resources, the main arduino site is http://arduino.cc./ You can find examples of some of the cool add-ons at http://sparkfun.com/
You might even have some fun with one of these things yourself!
I find this kind of interesting... While I haven't yet played with Android yet (or for that matter Windows on a netbook), this does seem to be an interesting development. I would *really* like to see a performance comparison between Android and Windows on the same netbook; both from a speed and resource consumption standpoint.
Overall, I really like the idea of Android, but think the platform is still too new for anyone to really pay it any serious attention. What really needs to happen is for cell phone manufacturers to have a compelling reason to use it on their cell phones.
That being said, I think Android is going to slowly whither away as a technological footnote over the next several years.
I guess Microsoft is trying to get people that don't understand C++ to program better in the language. IMHO, this will not solve fundamental problems with people programming C++, just cause them to learn the language slower by not having an experience working through a bastard of a bug. I think the world (and not just MS) needs to realize that writing a piece of complex software is difficult. Bugs like an errant memcpy of a subclass into a baseclass instance are *very* easy bugs to solve if you're looking for them. Memory overwrites are easy to detect if you are looking for them. Bad pointers are easy to detect if you're looking for them.
Such problems will always exist in software. I've found a fair number in my own code. What we *really* need to do is train a better caliber of programmer. OTOH, Microsoft seems hell-bent on trying to make writing software easy to do
A Black Swan is an event that is highly improbably, but statistically probable.
Yes, it is possible for a drive in a RAID 5 array to become absolutely inoperable, and for one of the other drives to have a read failure at the same time. This is highly unlikely though, and is not the Black Swan. The math use to calculate the likelihood of these two events occurring at the same time is faulty. The MTBF metric for hard drives is measured in 'soft failures'; this is very different from a 'hard failure'.
The difference between the two types of failures is that a soft failure, while a serious error, is something that the controlling operating system can work around if it detects it. It is extremely unlikely that a hard drive will exhibit a hard failure without having several soft failures first. It is even more unlikely that two drives in the same array will exhibit a hard failure within the length of time it takes to rebuild the array. In my experience, it is more likely that the software controlling the array will run into a bug rebuilding the array. I've seen this with several consumer-grade RAID controllers.
The true Black Swan is when a disk in the array catches fire, or does something equally as destructive to the entire array.
To echo other people's points, RAID increases availability, but only an off-site backup solves the data retention problem.
This is all great advice. The parts about not being defensive about code you've written are spot-on. I would add the following to the list:
Personally, over the past 10+ years of using Linux, I've stuck with either ext2 or ext3. They just work. They're the most commonly used filesystems in Linux, and the tools for recovering your data are the best of any filesystems available under Linux. This is because kernel developers use these filesystems on their crash boxes.
For me to pick a filesystem, I need to know that my data won't be lost. I use a computer for way too much... I'll trade performance for stability when it comes to irreplacable data.
That being said, I've been seeing some interesting things regarding ext4, tux3 and hammer. At least hammer & tux3 will offer you what you want, but neither are past beta stage. My advice is to stick w/ ext2/3 until either (1) ext4 has the features that you need or (2) that the LKML guys start using tux3 or hammer on their crash boxes.
Also, I'm not sure if you're thinking of 'file system compression' as an automatic defrag or of it as true file compression. If it's the former, there are defrag tools that you can run; if it's actual file compression to save space, you are wasting CPU cycles by trying to compress data at the FS level on your MythTV box... Try compressing an mpeg movie with gzip, you'll save maybe 1%. Far better to stick to ext2 for speed or ext3 for data integrity.
How do you make eye-contact with a New-Yorker?
Walk five feet behind him.
It's not a great joke, but it illustrates that in general people in urban areas around the world feel the same way as the Japanese. I've been an urbanite for quite a bit of my life, and while I think street view in kind of creepy, I don't feel the same way as this Japanese guy. Street-view is just way too useful to be against it.
If that doesn't satisfy your need, take a look at Berkley DB. It offers a more sophisticated interface than DBM.
Ok, it may be news to all of you, but Ingo Molnar has been working on a schedular that incorporates most of Con's ideas. It's called the 'Completely Fair Scheduler' (CFS), and its slated to be released in the 2.6.23 kernel.
If you'd like to read a bit about it and see some benchmarks comparing it to Con's SD scheduler, there's some very good coverage of it all over at kerneltrap.org
As for people calling for a fork of the Kernel, they obviously don't understand the Kernel development process, or how many forks currently exist.
I believe the Korn and Bash shell are both examples of prior art here... The Korn shell was in existance long before this patent application, and I believe bash has been around as long as well.
I can't wait for them to GPL their implementation. Hopefully there will be enough software in the Tivo that gets licesed under GPLv3 to put these assholes out of business.
Anyone out there have any examples of prior art?
Does that mean I get a reduction in the number of cookies I tell FireFox to reject?
Darn... I was getting used to saying no.
Keep in mind that governments around the world mandate much higher fuel efficiency in autos than the US. Europe especially so.
Its about time a movie with worse cover art beat out Kahn.
As a current Speakeasy subscriber, I am very worried about what the changes will be made to both the terms of service and data monitoring/privacy policies. Also, what impact will being owned by a public company have on policies?
If anyone from Speakeasy is able to thoughtfully answer these concerns, I'd like to know the answers. I have to say I am very disappointed in this deal... Best Buy is not a company I like to do business with. The only way that this deal would have been worse is if Speakeasy pimped themselves to Starbucks.
There is a reason why i rip everything gnome & kde related out of a linux distro after an install... the UI is too much like windows.
I still use fvwm1 (with all of its quirks/bugs) because it gets rid of some of the *basic* usability issues that gnome and kde fail to resolve.
To list a couple:
I think my point is that the gnome and kde projects are not so much about innovating as keeping up with microsoft... We need to create a community devoted to the idea of seeing what Redmond does and saying 'hey, thats interesting, but I can do that better'
This is what the kernel community does constantly... Linus is the gatekeeper, and he is right to critisize... When was the last time you totally changed the internal architecter of a subsystem of your project because you were wrong? For Linus it was the 2.4 MM (mid release cycle) /p?
Remember all of those stories regarding Google investing in ip-over-power lines a couple of years back? Google is doing a remarkably smart thing:
building data centers in rural areas near power generation facilities.
This is smart because: land there is cheap, is close to power, which means less chance of outage... and, well its close to power (see point 2)
remember those stories about google investing in ip-over-power?
They're already looking to invade newspapers, the next frontier is TV.
Think about it... I think Cringley is blowing a lot of smoke; he always does at the beginning of the year.
A couple of years ago I had to create a configuration system for FreeBSD systems in a data center... What I ended up using was a really crappy Perl module called PerlVision to do it (I was basing the code on a config system someone else wrote for some other systems). Anyway, it was pretty painless to do. You might consider writing the UI using a scripting language like perl or python that expose the ncurses bindings and use that to start any back-end processing that needs to happen. Also, as a design point, you might consider saving the configuration in a flat file that the backend reads. That way you can separate the UI development and testing completely from the actual product... If the need ever arises to create a fancier UI, you'll be able to then do it fairly painlessly.
I've personally made it about 20 hours into the story (including quite a bit of that time spent mindlessly leveling up :), and I have to say that I am really enjoying this game. While there are some things about the game that I could criticize, overall I think that this is one of the finest Final Fantasy games that I've played (and I've played all but XI and the Japanese only releases for the NES).
In terms of story, things do start off a bit choppy and the gambit system takes a while to get used to, but as you settle into the game you really start to have fun. You start to realize that your job in combat is to give general direction to the party, rather than direct every action of every character; this leads to some rewarding battles in which you just watch your characters kick ass on their own. In some ways, I think that this is somewhat better than with previous FF's, in that you don't just stupidly hold down the 'action confirm' button after setting up the cursor to always go to the last selected action.
Up until this game, I would have said that my favorite Final Fantasy would have been FF8, but I'm not so sure of that anymore. Like FF8, this one strives to make all of the various RPG elements (leveling, weapons upgrades and various magical abilities) somewhat believable. The fact that combat takes place in the same environment as the rest of the game play really adds an immersive and seemless quality to the game... A very welcome change.
As for the things that I don't like; there are not many... First and foremost would probably be that the license grid system is somewhat difficult to manage. Unlike other FF's, in order to use anything that you've bought (weapons, armor, spells, etc.), you must also have unlocked the license for that piece of equipment or ability; this leads you to sometimes sit in a weapons shop jumping back and forth between each character's license grid (to see whether its worth buying the weapon now) and the shop's merchandise list. Another thing that I've found to be somewhat annoying about the license grid is that it's really a lot of leveling up to get to the point where you've started to unlock the abilities that you really need, and oft times you have to unlock a bunch of abilities that you really don't care to unlock to get to the ones that you want. A good example of this is that you have to unlock a bunch of healing bonuses to level up the strength and HP of a character that you're trying to turn into a physical fighter. This doesn't make a whole lot of sense to me.
All and all though, a very lovingly crafted game... I might not give it a perfect 10/10, but its pretty close.
I think everyone here at Slashdot recognizes the dangers that these new DRM-infested devices are introducing into modern culture, and I think we can all agree that we would prefer companies to stop producing products that restrict our freedom.
Imagine what would happen if a company produced a portable MP3 and video player, similar to the Zune, that had P2P WiFi-connectivity, a BitTorrent client and possibly a scaled-down version of the Democracy Player . This might just cause the RIAA and MPAA to lose the ability to monitor file sharing and make it impossible to stop (unless the RIAA hires a bunch of thugs to sit in every subway car and bus across the country).
I call on us to figure out how to produce such a device. We need to send a message to companies like Apple, Microsoft and Sony that we will not accept devices broken by DRM.
Is anyone out there interested in helping to start a project to build and open-source piece of hardware to accomplish this?