The most useful feature of Nautilus is the scripts functionality, so simple & elegant.
I used to think so but then I discovered Nautilus Actions and things have been a lot better since then. But don't throw away your Nautilus scripts - you can use them with Actions. The beauty of Actions is that it is sensitive to the current selected file/files/directory/directories/mix so that only Actions that are appropriate are visible.
For example, if you have a script to make a thumbnail of one or more JPEGs, then you can set the criteria for Actions to only show you that action for selections of just JPEGs.
Give it a try - it's a really nice feature. Hopefully it will be part of GNOME 2.16.
I disagree. There are exactly 206 confirmed cases of bird flu. Of those 206, 113 have died, a 55% mortality rate.
Precisely. 206 confirmed cases. 113 dead. Those are the hard facts. The problem is that we don't know what the actual population of bird flu infections is. All we have are the most obvious and easy-to-collect figures - therefore saying that 1/2 of those who catch bird flu will die is totally bogus. I taught statistics and experimental methods at University - one of the issues that students really struggled with was the issue of accurate and appropriate sampling of a population. When dealing with colds, viruses, diseases, the medical profession only sees the worst cases. People with a sniffle don't normally go to a doctor. People who are delirious, spouting blood or dead will almost certainly see a medical professional.
The only way to get an unbiased indication is to actually go out and measure something in the field that is a good indicator of bird flu. Antibodies are the thing I would go out and look for in the general population. This would require actually going door to door and trying to get as many people as possible to give blood samples for testing. It is not appropriate simply to test everyone who turns up at the doctor's for precisely the reasons in the paragraph above. You don't have to measure everyone but you do have to sample enough people over the appropriate geographical region to get a reasonably balanced sample.
For example, the current virus has about a 50% mortality rate. It is very like when that when it mutates, this mortality rate will go down.
I have problems with these mortality figures. It's very easy to determine who died from bird flu - you have a body, death certificate, medical records, etc. It is NOT easy to work out who has had the bird flu and has survived in the general populace - not all sick people will have seen a doctor and some may not even have developed symptoms. Without doing a massive study looking for bird-flu antibodies, the mortality figures are almost certainly overblown, maybe by orders of magnitude. This applies whether we are talking about the impact on birds or on humans.
A new feature for Slashdot - Tagline of the Day Award (hereafter TotDA).
This is awarded for taglines for the news postings that actually manage to be thoughtful. A tagline that is witty, appropriate and insightful. That doesn't happen nearly enough and therefore the TotDA will not necessarily appear on a daily basis (despite the name).
I'm assuming that the Tom-Petty-Free-Playlists would be refering to the Last DJ, who plays what he wants to play. Not that that wasn't prescient - I can barely listen to the radio these days and find a real DJ. Internet radio is much better in that respect.
I should stick this in a Journal but I've written this here now. Bother. Oh well.
Anyway, it'll be cloned it within a month and then the slashdoterati will claim they invented it. Or maybe it'll run on Mono.
Cloned within a month? Sorry to rain on your parade but if you wanted an object shell, you could have been using one for more than a year already. Take a look at Object Shell which has been under development since October 2004. It's written in Python and uses Python objects.
I've been gaming around since Doom first blew the doors off the FPS genre. As the games have become more graphically impressive, the amount of work required to produce a mod for a specific engine has increased. One area where Epic seems to have done better than id software is in producing mod-friendly tools. Witness the huge number of mods for Unreal Tournament 2k4 versus, say, Doom 3.
Now it's not an entirely fair comparison - Doom 3 is a more complex engine to develop for. Models require more than just geometry and one texture map/shader. But that complexity seems to be denting the number of maps/models/mods being produced for Doom 3/Quake 4/etc. UT2k4 ships with a shed-load of tools for modding and maps can be created reasonably quickly from the stock models. UT2k4 also managed to provide a decent download system so that you can just log into a server and download all the parts required without having to go hunting through the many websites looking for the appropriate map/script/sound.
Unreal Engine 3 is going to require the same sort of resources as Doom 3/Quake 4 when it comes to creating completely new content. Maybe UE3 will benefit from modellers/modders having cut their teeth on the Doom3-style tech but it will be interesting to see just what creation tools come with UT2k7 and what the modding community creates.
Having made that clear, I have to say that OO simply isn't up to scratch on usability yet. The other day I was editing a word processor document, and using a lot of small capitals formatting. I wanted to add a button to the toolbar or a shortcut key to make this easier, but in OO you can't.
Can't? Try this:
Open the "Styles and Formatting" window.
Create a new Character Style by Right clicking in the window and click on "New"
Give this style a name - say "Small Caps".
Click the "Font Effects" tab. Click on "Effects" and select "Small Capitals". Click OK to close the dialogue.
Now you need to add the keystroke to apply this style. Tools->Customize->Keyboard.
Select Styles->Character Styles in the Category (left hand lower) pane. Select "Small Caps" in the Function pane. Select a key (say F4) in the Shortcut Keys pane. Click Modify.
You're done. F4 will now apply the Small Caps style to the selected text.
OOo is capable of many things. Maybe I should go add this to a wiki somewhere.
Cheers,
Toby Haynes
Ekiga: vocal communication technique
on
Ekiga 2.0 Released
·
· Score: 1, Informative
I might have been able to guess what GnomeMeeting did. I would have guessed that it was perhaps a collaborative whiteboard tool, perhaps with a dose of voice-chat built in. I'd bet it worked in Gnome.
And you would have been partly right, partly wrong. GnomeMeeting used to provide video/voice conferencing along with text chat. It used to be a NetMeeting clone but it has grown beyond that original aim.
I would have no bloody clue what an Ekiga is if the article hadn't mentioned it was the successor to GnomeMeeting. I'm sure it means something really appropriate in Sanskrit or something. How very clever.
And of course you know what a Skype is? Or what to Google means? Or how to what you would do with a AIM? For the record, Ekiga is a vocal technique used to communicate across distances.
Names are important but the old name for the project actually no longer reflected the usage or the abilities of the project. Having Gnome in the name is fine all the time that the project is just working on GNOME stuff but the Ekiga project now offers considerably more than just a GUI front end to other libraries.
Ekiga offers a GNOME UI for H.323 and SIP-based video/voice/text chat/conferencing. It also offers several libraries that are not Gnome-dependant to access/interoperate with various SIP/H.323 servers. Changing name is always a major pain but in this case I think it was warranted. At least having a flame war on Slashdot will mean that more people know about it.
I think Dell could quite easily take chance and actually stick a properly configured Linux machine out there. And it is not enough to just have a machine available if you can navigate into the deepest areas of the Dell website - it needs to be visible when you are picking out a workstation, a desktop or a laptop.
This question of "which distro" is a misleading one. Pick one that you think will meet the needs of your customers. Ubuntu is a nice fit for home machines and laptops. Dell already has some enterprise Linux machines out there so they could easily offer a choice of Ubuntu or Enterprise on workstations and servers. Once one distro works on a Dell machine, the likelihood is that any other distro of choice will also work. All this talk of fragmentation in the Linux distros misses the important point that open source is more about source-level compatibility than binary compatibility. As long as software can be compiled successfully on a Linux distro, it can be used.
It is also important to track the latest stable release. If Dell produced Ubuntu-configured machines, it should attempt to make sure that the version is current with the latest stable release. This would also encourage hardware manufacturers to provide Dell with Linux-supported hardware and that might in turn help increase the number of devices that have linux support. Wireless networking is a key area where support is tricky.
..it can't hold a candle to KDE for configuration. I mean, why would I want all these Gnome developers making choices for me?
Don't feed the trolls... don't feed the trolls... must... resist... aaahhh
Gnome has taken the route of trying to pick decent defaults for as much as possible. This ranges from the trivial (like the Window List always being a reasonable size, rather than specifying a minimum and maximum size) to more entrenched settings like button order based on your language left-to-right or right-to-left settings. Beyond that, it has aimed to keep the configuration/preferences window to just the most common options and remove any esoteric settings from the display. This has two benefits:
things behave reasonably
preference windows are quick to navigate and find the most common options
This is a marked change from KDE which offers pretty much all the tweaks available in the GUI. This does mean that KDE preferences tend to be heavily tabbed to provide the options in a reasonable amount of screen space. While a user is learning to use a KDE application, they may take some time to find the option they need in the tabs available.
Because Gnome does not expose all the configuration options in the application preferences, it's easy to assume that the defaults can't be changed or that custom bindings can't be set. The Gnome power-user who wants to, for example, bind multi-media keys to a script rather than one of the potted commands, needs to know about the GConf schemas and the gconf-editor tool. In this respect, Gnome provides for the user who doesn't care about complex configurations well while still allowing the arch-tweaker access to a whole host of advanced options.
A modern 3D video game ought to have:
[snip]
That's 5 threads at a bare minimum.
You missed one or more AI threads. All this talk of threads misses some of the more interesting (and difficult) areas of threading - messages and synchronisation.
Your sound effect thread will have dependencies on the character's position in the world and on the events going on in that world. This will include information from the physics thread (for collisions and explosions) and from the core world data area. This is probably most easily handled as a message queue of sound events - just stuff sound events into a sound event queue and forget about them - let the sound thread consume them FIFO-style.
Your AI thread will have dependencies on the physics thread (for moving object information) and on the general world data (for static objects and terrain info). Your AI thread can probably survive having just read-only access to the physics moving object data but you might want to have a (short-lived) latch on those structures if your AI thread requires stable data access. Your AI thread may have to update parameters in the physics data set to cope with changes to actors movements or vehicles motion in the AI decision tree. This will require write-latching to those physics data objects. Your physics thread requires accurate information from the input thread (handling the controls).
I could go on, but you should already have the picture - threads give you parallelism but they also require careful management of shared data structures. Threads may require synchronisation or information passed through message queues. Getting all this right, minimising hot latches (often by breaking a single latch into finer grained latches) and still running consistently, predictably and believably is not easy. Having a good toolkit which provides these features for you can make this a lot simpler for the developer but unless such a framework already exists, you probably will have to write your own.
I am a normal user and not a graphic designer. Thus, I do not use complicated features in Photoshop or GIMP, just the low level features. One of these, however, is crop. And crop sucks on GIMP. With Photoshop it is simple, I put a box around what I want to crop to and I crop. With GIMP there are three crops, none of which are very good.
Err? Okay - try this in the GIMP.
Shift-C (or click on the Crop tool in the button box - it looks like a knife).
Drag a box over the image - this should darken the unselected stuff to make it obvious what you are keeping.
The Audigy is a relatively expensive sound card with multiple hardware channels. I know some Linux fans may think everyone should pay $50 and up for audio output (in addition to paying 8x as much for dialup hardware in the form of an external controll-endowed modem). Meanwhile create types will continue to cut their teeth on Windows and Mac, and continue to stay away from Linux because of its atrocious audio behavior.
If you had written this before ALSA 0.9.6 you might have had an argument. Now you are spouting old inaccurate information. Almost any modern Linux system sets up (automatically) and uses the dmix and dsnoop plugins provided by ALSA to provide seamless, low latency mixing of any number of input streams, regardless of whether the actual physical device is capable of handling hardware mixing or whether the application is using hard-linked memory mapped access to the sound card (like Quake!). You don't need an Audigy or other "extra" sound card to do this - my cheapo intel mobo sound card chip i810 system works fine with three or four apps chucking sound at it. I run music 24x7 on that box. Alerts beep, mixed in with the music. Speech synthesis mixes in (using Festival, which knows nothing about the actual setup I have driving the audio). ALSA has, for the most part, delivered what people needed - good support for audio for home user and professional cards (like the RMEs).
Mort preceeds "Reaper Man" and is a better starting point.
If you want to work out where to start for each of the various plotlines, there is a diagram of the various streams of thought involved. Check out the reading guidelines for more options.
No, statistics show they are not getting better (though it looks like Microsoft is putting more efforts into improving their patch development process).
That probably reflects the standard problem with large-scale software development - as the product gets larger, the number of bugs increases and the difficulty of fixing each bug also increases. One of the reasons you see so many apps being duplicated and rewritten from the ground up is that it is often easier to start from scratch than fix a flawed program. That isn't an option for large projects which have a huge legacy of customers and code so you see an increasingly complex fixing-cycle. Automated systems for bug finding and stress testing help identify some of the stuff earlier but it isn't an easy problem.
That's not to say that MS gets off this hook - I'd be mad as hell if my servers got rooted and MS had known about the problem for months and hadn't worked on/released a fix. 135 days is a little scary... If MS was liable for costs incurred by customers on issues that MS actually knew about, they would either a) fix them more quickly or b) go bankrupt.
It was noted elsewhere that Microsoft spends six billion a year on R&D. If they hired mathematically-inclined software engineers at 100,000 a go, they'd be able to keep a small army of 10,000 such programmers. You can probably reverse-engineer a specification, prove, then re-engineer the code for about 10 lines an hour.
10 lines an hour? I doubt that is achievable even by an experienced developer who is new to the code in question. Maybe 10 lines a day in a huge C program. In C++ you might have a little more chance if the code is a shining example of good clean OO design where information-hiding has been well implemented and Java will stand you in even better stead as it does encourage better practices. But even Java won't save you from bad code or bad designs.
It's a better use of resources to identify problem areas of the code, get the original developers to provide a complete spec for that area and write a new clean, security-minded implementation. However that rarely gets done unless the problem code is actually causing serious trouble for the company - bad code that works well enough will probably survive because the cost of re-coding the bad area is larger than the cost of servicing the code in the field.
I teach the AP comp sci class at my high school. I stress repeatedly that they need to learn to program first, then do it in java second.
I'm hoping you meant work out the OO design first, then implement it in Java.
I've only recently had to pick up Java professionally - up till now, C/C++(not OO)/Perl/Lisp has been a good fit but I was asked to help out on a project that already had several person-years of Java code in it. So I had a lot of procedural and functional languages in my background but not really much OO.
I spent a fair amount of the first month getting my head into the Java thought process (thanks to Bruce Eckel's "Thinking in Java" and an experienced Java-developer's guidance). The key epiphany was realising that the design for an OO project really should be carefully thought out in terms of object life cycles, object->object interactions and object capabilities. You can code a procedural design in Java and you will eventually end up with spaghetti. Java lends itself to pure OO designs very nicely but gets awkward fast if you stray into procedural designs. The design needs to fit the language if you want to keep it going long term.
The point of whitelisting is simple - by the time a javascript exploit has run, it's too late. NoScript is taking the conservative (and security minded) approach of allowing you to keep a list of the sites you trust. Given that all you need to do to enable javascript on a page is to click on the NoScript symbol in the task bar, choose "allow" or "temporarily allow" and the page will reload with javascript on.
For anyone out there who wants a safer experience out on the web, you owe it to yourself to install the NoScript extension and only allow whitelisted sites to run Javascript. The exploit published this morning (more a DoS and only seems to affect some but not all installations of firefox 1.5 according to SANS) uses a Javascript loop to build up an enormous topic that ends up being written into your history.dat file causing buffer overflow issues. Without Javascript, this sort of exploit is much tougher.
I've eaten crocodile and the last thing I thought of was chicken. Maybe chicken that had decided that flying was for the birds and had chosen to devolve back to the sea for a couple of dozen millenia. There is something distinctly fishy about crocodile.
Well, I can see that microwaves will act on a volume of water, as compared to surface contact with a heating coil. Actually, what if you had a long length of pipe and had the magnetron positioned at one end, shooting upstream as the water moved past it? Theoretically, those microwaves could heat the water travelling down the entire length of the pipe span.
This is about the only advantage I can think of for microwaves over electric elements - you are heating a volume about the emitter. The microwaves will penetrate to about the skin depth for this wavelength - maybe a couple of centimeters or more but certainly not a whole length of pipe. Electic heaters will be able to deliver that power on the surface only and will rely on convection in the liquid to deliver this heat.
Still, the fundamentals apply. You stick 1kJ of energy into the water by microwaves or by electric heating element, you will get the same heat rise in the end. Whether heating the volume allows you to dump that energy into the water more quickly is an interesting idea. The other part of the equation is heat loss - does the electric element waste energy into its surroundings because of its mounting point? Maybe but I suspect that the electric element mount is plastic and well insulated. That said, plastic does have a high heat capacity so extended use might result in more heat loss to the surroundings. Whether the magnetron suffers similar heating/heatloss issues is another matter.
So this might be interesting but it certainly looks like marketing has buried the science at least in this press release.
Make sure you are compiling with a sane set of warnings enabled. Do this from the beginning and ensure that all code delivered to the project does not increase the number of critical warnings in your code. Disable any warnings you don't care about (but be certain that you can live without this knowledge first).
Use static analyis tools on the code to aid bug hunting. Java probably has the best support in this area - tools like FindBugs and PMD can save you WEEKS of trouble when used regularly.
Have a set of standard tests that must be run before any checkins - this will allow you to keep the code base moving along without compromising core function.
Have a centralised build system which keeps rebuilding AND testing the latest code base with whatever regression tools you have built. If possible, build on EVERY "complete" checkin so that you can always find out who broke the codebase fast.
Don't crucify your developers if they break the build unless they deliberately avoided some part of the usual pre-checkin tests. Use the break as an opportunity to assess weaknesses in the build system or the pre-checkin tests.
Mature projects either have all of the above, are in deep trouble or some combination of the above;-)
It's well worth remembering when discussing any aspect of British IT law that the present administration is headed by a man who was incapable of buying flowers for his wife over the Internet, what hope have they of understanding cryptography?
To quote Mr. Prosser as the study of cryptography rolls over them: "None at all".
Here's the link to the Phonebook project. Now that FUSE support is in the Linux kernel as of 2.6.14, this should be easier to get it installed.
Under the Regulation of Investigatory Powers Act it is already an offence not to hand over encryption keys to the police when requested to do so. If a person is detained, the police could investigate the hard disk and ask for the appropriate keys, if the suspect refuses they could then be charged under RIPA.
So then you need a method of being able to hide precisely what is encrypted and what is not. Look around and you'll find systems for filling a file system with chaff files to make finding the real data more interesting. One I looked at ended up with a filesystem with all the files apparently the same size, with constantly changing timestamps and all apparently contain random data. This system then allowed you to apply keys to make certain files readable while leaving the rest as noise. The point of this is that even the empty file system is full of rubbish files. It is impossible to tell (without the complete set of keys) precisely what is really data and what is just generated chaff. This gives you a lever of plausible deniability - if you are asked for the keys to the repository, you can hand over the keys and let them at it. It would be difficult (never say never) to correctly identify encrypted files amongst the chaff which were not covered by the keys provided.
Slashdot Mirror
I used to think so but then I discovered Nautilus Actions and things have been a lot better since then. But don't throw away your Nautilus scripts - you can use them with Actions. The beauty of Actions is that it is sensitive to the current selected file/files/directory/directories/mix so that only Actions that are appropriate are visible.
For example, if you have a script to make a thumbnail of one or more JPEGs, then you can set the criteria for Actions to only show you that action for selections of just JPEGs.
Give it a try - it's a really nice feature. Hopefully it will be part of GNOME 2.16.
Cheers,
Toby Haynes
I disagree. There are exactly 206 confirmed cases of bird flu. Of those 206, 113 have died, a 55% mortality rate.
Precisely. 206 confirmed cases. 113 dead. Those are the hard facts. The problem is that we don't know what the actual population of bird flu infections is. All we have are the most obvious and easy-to-collect figures - therefore saying that 1/2 of those who catch bird flu will die is totally bogus. I taught statistics and experimental methods at University - one of the issues that students really struggled with was the issue of accurate and appropriate sampling of a population. When dealing with colds, viruses, diseases, the medical profession only sees the worst cases. People with a sniffle don't normally go to a doctor. People who are delirious, spouting blood or dead will almost certainly see a medical professional.
The only way to get an unbiased indication is to actually go out and measure something in the field that is a good indicator of bird flu. Antibodies are the thing I would go out and look for in the general population. This would require actually going door to door and trying to get as many people as possible to give blood samples for testing. It is not appropriate simply to test everyone who turns up at the doctor's for precisely the reasons in the paragraph above. You don't have to measure everyone but you do have to sample enough people over the appropriate geographical region to get a reasonably balanced sample.
Cheers,
Toby Haynes
I have problems with these mortality figures. It's very easy to determine who died from bird flu - you have a body, death certificate, medical records, etc. It is NOT easy to work out who has had the bird flu and has survived in the general populace - not all sick people will have seen a doctor and some may not even have developed symptoms. Without doing a massive study looking for bird-flu antibodies, the mortality figures are almost certainly overblown, maybe by orders of magnitude. This applies whether we are talking about the impact on birds or on humans.
Cheers,
Toby Haynes
This is awarded for taglines for the news postings that actually manage to be thoughtful. A tagline that is witty, appropriate and insightful. That doesn't happen nearly enough and therefore the TotDA will not necessarily appear on a daily basis (despite the name).
I'm assuming that the Tom-Petty-Free-Playlists would be refering to the Last DJ, who plays what he wants to play. Not that that wasn't prescient - I can barely listen to the radio these days and find a real DJ. Internet radio is much better in that respect.
I should stick this in a Journal but I've written this here now. Bother. Oh well.
Cheers,
Toby Haynes
Cloned within a month? Sorry to rain on your parade but if you wanted an object shell, you could have been using one for more than a year already. Take a look at Object Shell which has been under development since October 2004. It's written in Python and uses Python objects.
Cheers,
Toby Haynes
I detect an Orbital devotee. Or maybe a Star Trek fan. Or both :-)
Cheers,
Toby Haynes
Now it's not an entirely fair comparison - Doom 3 is a more complex engine to develop for. Models require more than just geometry and one texture map/shader. But that complexity seems to be denting the number of maps/models/mods being produced for Doom 3/Quake 4/etc. UT2k4 ships with a shed-load of tools for modding and maps can be created reasonably quickly from the stock models. UT2k4 also managed to provide a decent download system so that you can just log into a server and download all the parts required without having to go hunting through the many websites looking for the appropriate map/script/sound.
Unreal Engine 3 is going to require the same sort of resources as Doom 3/Quake 4 when it comes to creating completely new content. Maybe UE3 will benefit from modellers/modders having cut their teeth on the Doom3-style tech but it will be interesting to see just what creation tools come with UT2k7 and what the modding community creates.
Cheers,
Toby Haynes
Can't? Try this:
OOo is capable of many things. Maybe I should go add this to a wiki somewhere.
Cheers,
Toby Haynes
I might have been able to guess what GnomeMeeting did. I would have guessed that it was perhaps a collaborative whiteboard tool, perhaps with a dose of voice-chat built in. I'd bet it worked in Gnome.
And you would have been partly right, partly wrong. GnomeMeeting used to provide video/voice conferencing along with text chat. It used to be a NetMeeting clone but it has grown beyond that original aim.
I would have no bloody clue what an Ekiga is if the article hadn't mentioned it was the successor to GnomeMeeting. I'm sure it means something really appropriate in Sanskrit or something. How very clever.
And of course you know what a Skype is? Or what to Google means? Or how to what you would do with a AIM? For the record, Ekiga is a vocal technique used to communicate across distances.
Names are important but the old name for the project actually no longer reflected the usage or the abilities of the project. Having Gnome in the name is fine all the time that the project is just working on GNOME stuff but the Ekiga project now offers considerably more than just a GUI front end to other libraries.
Ekiga offers a GNOME UI for H.323 and SIP-based video/voice/text chat/conferencing. It also offers several libraries that are not Gnome-dependant to access/interoperate with various SIP/H.323 servers. Changing name is always a major pain but in this case I think it was warranted. At least having a flame war on Slashdot will mean that more people know about it.
Cheers,
Toby Haynes
This question of "which distro" is a misleading one. Pick one that you think will meet the needs of your customers. Ubuntu is a nice fit for home machines and laptops. Dell already has some enterprise Linux machines out there so they could easily offer a choice of Ubuntu or Enterprise on workstations and servers. Once one distro works on a Dell machine, the likelihood is that any other distro of choice will also work. All this talk of fragmentation in the Linux distros misses the important point that open source is more about source-level compatibility than binary compatibility. As long as software can be compiled successfully on a Linux distro, it can be used.
It is also important to track the latest stable release. If Dell produced Ubuntu-configured machines, it should attempt to make sure that the version is current with the latest stable release. This would also encourage hardware manufacturers to provide Dell with Linux-supported hardware and that might in turn help increase the number of devices that have linux support. Wireless networking is a key area where support is tricky.
Cheers,
Toby Haynes
Don't feed the trolls ... don't feed the trolls ... must ... resist ... aaahhh
Gnome has taken the route of trying to pick decent defaults for as much as possible. This ranges from the trivial (like the Window List always being a reasonable size, rather than specifying a minimum and maximum size) to more entrenched settings like button order based on your language left-to-right or right-to-left settings. Beyond that, it has aimed to keep the configuration/preferences window to just the most common options and remove any esoteric settings from the display. This has two benefits:
This is a marked change from KDE which offers pretty much all the tweaks available in the GUI. This does mean that KDE preferences tend to be heavily tabbed to provide the options in a reasonable amount of screen space. While a user is learning to use a KDE application, they may take some time to find the option they need in the tabs available.
Because Gnome does not expose all the configuration options in the application preferences, it's easy to assume that the defaults can't be changed or that custom bindings can't be set. The Gnome power-user who wants to, for example, bind multi-media keys to a script rather than one of the potted commands, needs to know about the GConf schemas and the gconf-editor tool. In this respect, Gnome provides for the user who doesn't care about complex configurations well while still allowing the arch-tweaker access to a whole host of advanced options.
Cheers,
Toby Haynes
A modern 3D video game ought to have: [snip] That's 5 threads at a bare minimum.
You missed one or more AI threads. All this talk of threads misses some of the more interesting (and difficult) areas of threading - messages and synchronisation.
Your sound effect thread will have dependencies on the character's position in the world and on the events going on in that world. This will include information from the physics thread (for collisions and explosions) and from the core world data area. This is probably most easily handled as a message queue of sound events - just stuff sound events into a sound event queue and forget about them - let the sound thread consume them FIFO-style.
Your AI thread will have dependencies on the physics thread (for moving object information) and on the general world data (for static objects and terrain info). Your AI thread can probably survive having just read-only access to the physics moving object data but you might want to have a (short-lived) latch on those structures if your AI thread requires stable data access. Your AI thread may have to update parameters in the physics data set to cope with changes to actors movements or vehicles motion in the AI decision tree. This will require write-latching to those physics data objects. Your physics thread requires accurate information from the input thread (handling the controls).
I could go on, but you should already have the picture - threads give you parallelism but they also require careful management of shared data structures. Threads may require synchronisation or information passed through message queues. Getting all this right, minimising hot latches (often by breaking a single latch into finer grained latches) and still running consistently, predictably and believably is not easy. Having a good toolkit which provides these features for you can make this a lot simpler for the developer but unless such a framework already exists, you probably will have to write your own.
Cheers,
Toby Haynes
Err? Okay - try this in the GIMP.
I fail to see what is causing you problems.
Cheers,
Toby Haynes
If you had written this before ALSA 0.9.6 you might have had an argument. Now you are spouting old inaccurate information. Almost any modern Linux system sets up (automatically) and uses the dmix and dsnoop plugins provided by ALSA to provide seamless, low latency mixing of any number of input streams, regardless of whether the actual physical device is capable of handling hardware mixing or whether the application is using hard-linked memory mapped access to the sound card (like Quake!). You don't need an Audigy or other "extra" sound card to do this - my cheapo intel mobo sound card chip i810 system works fine with three or four apps chucking sound at it. I run music 24x7 on that box. Alerts beep, mixed in with the music. Speech synthesis mixes in (using Festival, which knows nothing about the actual setup I have driving the audio). ALSA has, for the most part, delivered what people needed - good support for audio for home user and professional cards (like the RMEs).
Cheers,
Toby Haynes
Mort preceeds "Reaper Man" and is a better starting point.
If you want to work out where to start for each of the various plotlines, there is a diagram of the various streams of thought involved. Check out the reading guidelines for more options.
Cheers,
Toby Haynes
That probably reflects the standard problem with large-scale software development - as the product gets larger, the number of bugs increases and the difficulty of fixing each bug also increases. One of the reasons you see so many apps being duplicated and rewritten from the ground up is that it is often easier to start from scratch than fix a flawed program. That isn't an option for large projects which have a huge legacy of customers and code so you see an increasingly complex fixing-cycle. Automated systems for bug finding and stress testing help identify some of the stuff earlier but it isn't an easy problem.
That's not to say that MS gets off this hook - I'd be mad as hell if my servers got rooted and MS had known about the problem for months and hadn't worked on/released a fix. 135 days is a little scary... If MS was liable for costs incurred by customers on issues that MS actually knew about, they would either a) fix them more quickly or b) go bankrupt.
Cheers,
Toby Haynes
10 lines an hour? I doubt that is achievable even by an experienced developer who is new to the code in question. Maybe 10 lines a day in a huge C program. In C++ you might have a little more chance if the code is a shining example of good clean OO design where information-hiding has been well implemented and Java will stand you in even better stead as it does encourage better practices. But even Java won't save you from bad code or bad designs.
It's a better use of resources to identify problem areas of the code, get the original developers to provide a complete spec for that area and write a new clean, security-minded implementation. However that rarely gets done unless the problem code is actually causing serious trouble for the company - bad code that works well enough will probably survive because the cost of re-coding the bad area is larger than the cost of servicing the code in the field.
Cheers,
Toby Haynes
I'm hoping you meant work out the OO design first, then implement it in Java.
I've only recently had to pick up Java professionally - up till now, C/C++(not OO)/Perl/Lisp has been a good fit but I was asked to help out on a project that already had several person-years of Java code in it. So I had a lot of procedural and functional languages in my background but not really much OO.
I spent a fair amount of the first month getting my head into the Java thought process (thanks to Bruce Eckel's "Thinking in Java" and an experienced Java-developer's guidance). The key epiphany was realising that the design for an OO project really should be carefully thought out in terms of object life cycles, object->object interactions and object capabilities. You can code a procedural design in Java and you will eventually end up with spaghetti. Java lends itself to pure OO designs very nicely but gets awkward fast if you stray into procedural designs. The design needs to fit the language if you want to keep it going long term.
Cheers,
Toby Haynes
Cheers,
Toby Haynes
Cheers,
Toby Haynes
I've eaten crocodile and the last thing I thought of was chicken. Maybe chicken that had decided that flying was for the birds and had chosen to devolve back to the sea for a couple of dozen millenia. There is something distinctly fishy about crocodile.
Cheers,
Toby Haynes
This is about the only advantage I can think of for microwaves over electric elements - you are heating a volume about the emitter. The microwaves will penetrate to about the skin depth for this wavelength - maybe a couple of centimeters or more but certainly not a whole length of pipe. Electic heaters will be able to deliver that power on the surface only and will rely on convection in the liquid to deliver this heat.
Still, the fundamentals apply. You stick 1kJ of energy into the water by microwaves or by electric heating element, you will get the same heat rise in the end. Whether heating the volume allows you to dump that energy into the water more quickly is an interesting idea. The other part of the equation is heat loss - does the electric element waste energy into its surroundings because of its mounting point? Maybe but I suspect that the electric element mount is plastic and well insulated. That said, plastic does have a high heat capacity so extended use might result in more heat loss to the surroundings. Whether the magnetron suffers similar heating/heatloss issues is another matter.
So this might be interesting but it certainly looks like marketing has buried the science at least in this press release.
Cheers,
Toby Haynes
Mature projects either have all of the above, are in deep trouble or some combination of the above ;-)
Cheers,
Toby Haynes
To quote Mr. Prosser as the study of cryptography rolls over them: "None at all".
Here's the link to the Phonebook project. Now that FUSE support is in the Linux kernel as of 2.6.14, this should be easier to get it installed.
Cheers,
Toby Haynes
So then you need a method of being able to hide precisely what is encrypted and what is not. Look around and you'll find systems for filling a file system with chaff files to make finding the real data more interesting. One I looked at ended up with a filesystem with all the files apparently the same size, with constantly changing timestamps and all apparently contain random data. This system then allowed you to apply keys to make certain files readable while leaving the rest as noise. The point of this is that even the empty file system is full of rubbish files. It is impossible to tell (without the complete set of keys) precisely what is really data and what is just generated chaff. This gives you a lever of plausible deniability - if you are asked for the keys to the repository, you can hand over the keys and let them at it. It would be difficult (never say never) to correctly identify encrypted files amongst the chaff which were not covered by the keys provided.
Cheers,
Toby Haynes