Even the best and fastest xml parser will be much slower than a binary one (even a pretty badly written one). and that's even assuming it isn't trying to implement all of the stupid little rules you need to implement to make it fully compliant.
"SourceForge.net is the world's largest open source software development Web site, providing more than 160,000 projects and over 1,700,000 registered users with a centralized resource for managing projects, issues, communications, and code. With over 70,000 of those projects based on Microsoft technology, SourceForge.net and Microsoft have worked together to provide the tools, programs and resources to help developers be more successful. Learn more..."
"Dela Cruz noted that within the SourceForge developer community, there are more than 77,000 listed applications that support Windows, more than half the same number of apps that work on Windows alone."
"By embracing diverse application development and business models, Microsoft provides a world of choice in which individuals and organizations can pursue their goals based on what uniquely inspires them. Whether you are a developer who wants to learn new skills, connect with the community, or build a business-or a systems administrator dealing with complex interoperability and business demands-Microsoft participates in an ecosystem that offers you the tools, resources, and programs to help you succeed."
Coincidence? Probably.
Ahh, it's all about choice now. Choice of where you want to run your applications, so long as it runs on windows anyway.
I'm sure we'll be seeing more of that word over the next 6 months, and plenty of times on the front page of slashdot and sourceforge to boot.
It is nothing like communism. Communism would be if RMS (for example, or the FSF) told everyone what they could work on (only) and had complete centralised control.
Free software competes in a completely open market where all players are on a totally level playing field.
This has been my experience, over and over. BS is full of BS on this one. I suspect the code he was talking about was little more than straight C with some object syntax.
If a package is not well maintained - or even if it is and it was written using an older or different compiler, it will almost always require work to get it building. I've given up downloading 'sample code' if it is written in C++ because it usually just wont work without more effort than I care to spend. Just 2 days ago I tried to customise the blackbox window manager, and it wouldn't build on a Fedora 9 box because of some changes to stdlib/stdio or something. The fixes required weren't big, but it just didn't build out of the box, and required some patching for gcc 3.4.
C on the other hand, rarely has this problem - it is normally the other way around, using c-nothing features against a c-90 compiler. I'm sure this is one of the reasons C++ never replaced C outright (among the many other reasons such as it taking so long to be standardised and implemented even remotely well). That a language with such compiler dependencies has got as far as it has is a testament to marketing effort I suspect. And probably more than a little to do with the intentionally confusing name that makes it sound like C. Most people even make the mistake of saying 'C/C++' all the time when they are very distinct languages. I think all everyone ever really wanted was 'C with objects', not the mess they ended up with (which is why java and c-hash had an instant market).
1) Nothing wrong with being clever, but some concise comments as to what is going on should be a rule. Definitely not 'a ton' of documentation - nobody will ever read it, and if you need a ton of doco to explain it, it probably isn't terribly clever in the first place. Sometimes cleverness is needed to get around problems in the language you're using, or a bit of cleverness can increase code quality and reduce maintenance.
2) No, don't optimise unnecessarily. A subtle difference of tone if not meaning. I've seen more than one occasion where people insisted on using a first-principles algorithm for the sake of 'clarity' even when there are known better solutions available - e.g. for sorting. All they ended up with was unusable, slow code that needed to be rewritten. Optimisation has deeper issues beyond micro-optimisations in your for loops. For example getting the design correct and scalable is a part of the optimisation process, and if you do not take performance into account when designing many systems they will not scale when they need to, and suddenly you find yourself in real trouble.
Obfuscated code can be relative. Not everyone has the same understanding of the problem at hand, let alone the same level of skill. Many mathematical proofs escape my understanding, and look pretty obfuscated in their terse notation, but that doesn't mean they don't make perfect sense to the author and others. SQL can concisely represent complicated queries that are often not terribly readable, and understanding and analysing performance is an issue in almost every query you write. Just because you may not understand pointer arithmetic in C does not make it a bad and evil thing.
Some problems do not map well to the language they are written in - and you usually don't have the luxury of using or inventing or learning a better language for the problem. Other problems are just hard. Thus, the code may be complicated by necessity. Explaining what the code is trying to do might be complicated too - there's just no way around it sometimes, and over documenting doesn't help. Documentation can easily get stale and the meaning of words can be misinterpreted in ways straight code cannot.
Professors say these things, and they are good things to say to novices. But over time and with experience you know when to listen to them and when not to.
Of course, it means they have to pay for the licenses for the codecs.
Perhaps every sale even sends a little bit of money to M$.
Nice way to leverage the free cost of free software while at the same time selling out to proprietary interests and immoral anti-competitive laws like patents.
Although it was a one-off payment, they even got some money out of the Samba team. Novell are long gone. It seems they're the ones (proprietary interests) dictating the terms under which free software is now developed and used.
Yes, lets hide all those 'nasty details', like GNU and Linux being Free Software.
You wouldn't want users knowing they are actually allowed to modify or copy all of the software with no cost or legal problems. Lets hide all those details for those silly overweight four-eye geek types to worry about.
Although there is nothing in this use of scanf that warrants that statement (in the pseudo code sense at least - like any other c function you need to check the return code). No different to using Int32.TryParse(string, out foo) and ignoring it's return code.
scanf used on integers can be perfectly safe. And any other input mechanism that read an integer would still fail with that loop - it has nothing to do with scanf. Like goto's, scanf is misunderstood and blindly called bad without understanding why - which is the problem, not the function(ality) itself. Anyone who doesn't understand their use enough to know when it is unsafe should not be calling for anyone who uses it to be fired.
Back on topic, I think money would be better spent on better programmers or training than only slightly useful tools which give you a false sense of security.
American sliced bread has a lot of sugar in it - it is very sweet, almost cake-like in its sweetness. Quite disgusting for what you use bread for. I started making my own bread while I was there because it was so sweet you couldn't eat it with savoury toppings like cheese or vegemite. And although some restaurants had italian or french bread I couldn't find it in the shops.
And strangely, it never seemed to go off, and was never fresh either - always in some half-state of slightly stale but never mouldy. Shit knows what else is in the stuff - must be full of preservatives they don't use here. It almost seems a stretch calling it bread at all.
Well one thing the distro's seem to have agreed upon - foistering bloated slow software on their users.
I tried to install Fedora and Ubuntu on an old laptop last weekend and had no end of frustration, and even after considerable tweaking the experience is far from perfect. This is a machine on which I easily developed 1000's of lines of code running emacs and netscape and gdb and evolution (ok it struggled a bit with all that at once, but only then).
The main problems are:
GDM. It looks pretty but it is way too heavy for a login manager. Installing and enabling XDM helps but the configuration for XDM has fallen by the wayside and doesn't appear to be very well maintained. How to turn it on keeps changing, it is badly documented, and doesn't always work.
Desktop applets. Even using xfce there are a bunch of crapplets I just don't need running all the time, and many of them use considerable resources. Battery applet, printer applet, system updates applet - consume tens of megabytes for a machine which has no printer, no battery, and I can easily manage updates myself. (on a side note, xfce is also rather bloated - 80mb for the 'desktop' application that shows a background and a few icons? It isn't even the file manager?).
Python applets and system tools. Python is not a system language, it is not an application language. I think running yum consumed over 100mb of memory to install a single package. WTF? Then you have multiple copies of the VM running shitty little buggy one-button crapplets consuming multi-10's of megabytes that I don't need. If they insist on using a shitty language like python, then they have to do it smarter. Run a script server, once (per user if you must), and run all scripts through it, otherwise you've basically got 'x' number of custom-operating-system instances running for 'x' scripts. Hint: it doesn't scale. If you're language has a shitty VM that doesn't support threading and doesn't support secure isolated execution of multiple programmes concurrently, then fuck it off and get something that does. Food for though: if you've got a simple language that's easy to use, you're probably going to get (on average) simple applications written by people who only know how to use simple languages. e.g. look at visual basic and it's plethora of crap applications.
Actually - yes it is true. Almost every application would benefit from multi-threading to some extent.
You dismiss ui interactivity like it isn't important - but it is. But that isn't 'at best' at all. Also note that many gui toolkits have work-arounds so you don't need to use threads (i.e. io, timer events, etc) - but all these are are just threading anyway, and often harder to use and harder to debug than 'real' threads.
Lets look at a few common applications and see how threading helps them:
1. graphics applications. Using 4 cores to perform your blur filter is going to be faster than 1, and blocking the ui while you're doing it (or doing it in chunks and polling for new events is even slower). 1.1 viewing pictures. Threads can be used to easily pre-fetch and decode pictures before they are shown. 2. playing music. using a thread to play the music with a gui controller running separately will be easier to write and debug than using timout events and non-blocking i/o. Multiply the issue if you're playing and mixing multiple audio streams at once. Also note an os thread context switch is often going to be more efficient than a manual context switch (i.e. we have new data, lets re-load all of our state from where we were before, do the work, save our state manually because we've run out of work to do, return to the event loop, vs read data, process (our state is already 'here'), wait for more data) - so it might even use less total cpu time. 3. i/o bound applications. Using threads you can pre-fetch data in ways the operating system cannot (it will only pre-fetch linearly), and thus process with reduced latency and potentially reduced overall running time. Again you can do it with select/poll but often using a thread will be simpler to code and debug (a simple read loop vs register event, listen for event, process event, repeat). 4. business applications. threads can be pre-calculating results as you're using the ui, so you can improve the workflow of the user - e.g. so they don't have to hit a calculate button and wait for results. And many hard-to-calculate results can be calculated in parallel so you get your results faster. 5. online transaction processing. well processes probably work here as well as threads - but at some point things need to go through some thread-like mechanism. e.g. database access or filesystem access 'threaded' by the kernel. 6. web browsers. threads are essential here so your flash based adverts don't slow the rest of the application down too much. Again using threads is easier than polling.
In almost all non-trivial interactive applications threading can improve the user experience and reduce overall running time, while at the same time simplifying coding and debug (even on a single-cpu machine). It will also accelerate any parallel algorithm (on suitable hardware) and possibly simplify its code and debug as well.
Threads are not perfect but they are a practical solution to a real problem - how to get improved performance using modern hardware which is only increasing in its number of cores. So the opportunities in which threads increase performance will only increase. And auto-parellising languages/compilers will always be years away. There are real practical reasons java emphasises thread's so much - remember it was invented by a hardware manufacturer who knew where cpu's were going.
All interactive gui applications that do non-trivial work have to use threads - but they might not be using pthreads. Registering an event handler and callback and processing it, or doing a little bit of work at a time in an 'idle handler' is just a crude form of threading - one that has no debugger support and can be a total nightmare to debug. If there were 3 processing loops - a timeout, an idle handler (for say applying biz-wang filter on photoshop a few rows at a time), and handling user input, which do you think would be easier to debug. Using threads where you can view each thread's stack exactly where it is at a given point in time, or looking at some internal gui toolkit 'events pending' list which you may not even be able to see from the debugger in any form other than hex codes?
Actually misspelled is just another example of a grating Americanism. Like 'I could care less' which makes no literal sense in the places they insist on using it.
Misspelt is the correct English spelling, and shows up as correctly spelt in my editor (as does spelt, of course).
Yeah you're right, slashdot does need a WRONG moderation type.
In gtk+ everything is automatically laid out using layout managers. It makes absolutely zero difference to the application writer whether it is manual resize or not.
You have to explicitly override this behaviour and if you do you greatly increase your maintenance issues - e.g. now you have to manually account for different screen resolutions and font sizes rather than letting the system automatically size for you.
Not having resizable windows is just stupid - how can the same application run on a PDA screen and your dual-screen 24" machine at work without resizing?
Look, comparing ubuntu to windows is all well and good. It's what 'mainstream users' think computers are - windows.
But for fucks sake, don't use it as a reason to turn Ubuntu into windows! It's already losing it's "linux-ness" by being too newbie focussed.
Anyway - most of the 'problems' were with proprietary software. That is the fault of the proprietary vendors - how about laying blame where it belongs. A bare bones windows install doesn't even have half of those programs - she'd be pretty proper fucked on windows doing all those things if someone hadn't loaded her box with 'pirated' shit to start with. Some of the comments of the author indicate he doesn't really know what's going on either (e.g. using gimp to 'photoshop' a picture, and wondering why gimp isn't identical to photoshop. hint: it isn't photoshop).
Mental aid? But that is exactly the issue that literate programming addresses - so it would obviously be totally pointless for Knuth. Defining and communicating tasks in very small chunks is precisely what it is for.
Anyway - although i've had grand ideas to use unit tests and even written quite a few - in the end they've never actually been all that useful. Usually nobody but the original author uses them anyway because discipline is lacking, and what they test will usually show up pretty fast in other testing anyway.
It's a good idea, but like documentation it is usually to hard to keep them up to date - e.g. when you actually want the behaviour to change you have to go and fix all of the tests. Which actually means re-testing the tests. You spend more time maintaining your tests than writing the code, for very little practical benefit.
That might be more 'literate', but it isn't 'literate programming' at all. Most of Knuth's code for example, which is the pre-eminent example of literate programming (he invented it) - uses minimalist variable names.
And FWIW if the second example was more realistic (i.e. just the variable name was abbreviated to d) I would find the it more readable - 'readability' is very subjective.
Not true, write speed isn't all that important. The reason why hard disk drives are such huge bottle necks is because reading data is a synchronous operation. When you read a file, you do so because you need to do something with its data. Right now, not some time in the future. So your program has to wait (block) until the hard disk has finished reading all data. Depending on how far the disk head has to seek, the wait may take a huge amount of time.
Writes cannot usually be performed asynchronously though - because they need to conform to the api presented. e.g. close() or sync() guarantee the data is written to non-volatile storage, whatever that may be. Being able to cache bits of the write in memory may help but at the end of the day it's all gotta be stored once close() returns, so it makes no real difference to many applications apart from being able to better store the data on disk. e.g. a compile writes files which are read by another programme later.
Also, your programme doesn't always have to block until the disk is finished - it just chooses to do so. There's nothing to stop your application using asynchronous i/o to load ahead of time what it needs. The kernel will already do some look ahead for sequential access, but you can certainly help it along by doing it manually. Many many algorithms can be modified this way - even many random access ones. Then there's things like b-trees (to minimise external accesses) and threads (to take advantage of any cycles otherwise being wasted). There's a reason Java throws so much at threads - its one way to get around the cpu/memory/disk impedance mismatch that is relatively easy to understand.
APIs are there to abstract away things like this on purpose (infact the whole system is geared for it - l1, l2 cache, main memory and virtual memory are all hidden to the application coder by default), so most programmers don't delve further, nor have the time to. They just assume a write or read will happen in fast-enough time and be done with it (or force the user to upgrade to faster equipment).
Even if disks get >> faster, they're sill << slower than main memory/cache, so the problem still remains - you're still only getting a limited amount of performance out of the system if you're software isn't smart enough (and the kernel can't do everything).
Slashdot Mirror
Even the best and fastest xml parser will be much slower than a binary one (even a pretty badly written one). and that's even assuming it isn't trying to implement all of the stupid little rules you need to implement to make it fully compliant.
What's so 'massive evolution'ary about that?
Only a few years late to the game I guess.
Hmm, why does this ring a bell?
Sourceforge ... check. ... check. ... check.
Windows-only 'open source' application
Lots of publicity
Hmm.
http://www.microsoft.com/opensource/community.mspx
"SourceForge.net is the world's largest open source software development Web site, providing more than 160,000 projects and over 1,700,000 registered users with a centralized resource for managing projects, issues, communications, and code. With over 70,000 of those projects based on Microsoft technology, SourceForge.net and Microsoft have worked together to provide the tools, programs and resources to help developers be more successful. Learn more..."
http://newsinfo.inquirer.net/breakingnews/infotech/view/20080624-144528/Microsoft-to-developers-Open-source-is-a-choice
"Dela Cruz noted that within the SourceForge developer community, there are more than 77,000 listed applications that support Windows, more than half the same number of apps that work on Windows alone."
http://www.microsoft.com/opensource/choice.mspx
"By embracing diverse application development and business models, Microsoft provides a world of choice in which individuals and organizations can pursue their goals based on what uniquely inspires them. Whether you are a developer who wants to learn new skills, connect with the community, or build a business-or a systems administrator dealing with complex interoperability and business demands-Microsoft participates in an ecosystem that offers you the tools, resources, and programs to help you succeed."
Coincidence? Probably.
Ahh, it's all about choice now. Choice of where you want to run your applications, so long as it runs on windows anyway.
I'm sure we'll be seeing more of that word over the next 6 months, and plenty of times on the front page of slashdot and sourceforge to boot.
It is nothing like communism. Communism would be if RMS (for example, or the FSF) told everyone what they could work on (only) and had complete centralised control.
Free software competes in a completely open market where all players are on a totally level playing field.
That sounds a lot more like capitalism to me.
This has been my experience, over and over. BS is full of BS on this one. I suspect the code he was talking about was little more than straight C with some object syntax.
If a package is not well maintained - or even if it is and it was written using an older or different compiler, it will almost always require work to get it building. I've given up downloading 'sample code' if it is written in C++ because it usually just wont work without more effort than I care to spend. Just 2 days ago I tried to customise the blackbox window manager, and it wouldn't build on a Fedora 9 box because of some changes to stdlib/stdio or something. The fixes required weren't big, but it just didn't build out of the box, and required some patching for gcc 3.4.
C on the other hand, rarely has this problem - it is normally the other way around, using c-nothing features against a c-90 compiler. I'm sure this is one of the reasons C++ never replaced C outright (among the many other reasons such as it taking so long to be standardised and implemented even remotely well). That a language with such compiler dependencies has got as far as it has is a testament to marketing effort I suspect. And probably more than a little to do with the intentionally confusing name that makes it sound like C. Most people even make the mistake of saying 'C/C++' all the time when they are very distinct languages. I think all everyone ever really wanted was 'C with objects', not the mess they ended up with (which is why java and c-hash had an instant market).
"First, it's confirmation that the white stuff at the poles really is ice (and not some unknown martian substance that just looks like ice)."
Or perhaps it is just weird martian substance that still looks like ice, even close up?
1) Nothing wrong with being clever, but some concise comments as to what is going on should be a rule. Definitely not 'a ton' of documentation - nobody will ever read it, and if you need a ton of doco to explain it, it probably isn't terribly clever in the first place. Sometimes cleverness is needed to get around problems in the language you're using, or a bit of cleverness can increase code quality and reduce maintenance.
2) No, don't optimise unnecessarily. A subtle difference of tone if not meaning. I've seen more than one occasion where people insisted on using a first-principles algorithm for the sake of 'clarity' even when there are known better solutions available - e.g. for sorting. All they ended up with was unusable, slow code that needed to be rewritten. Optimisation has deeper issues beyond micro-optimisations in your for loops. For example getting the design correct and scalable is a part of the optimisation process, and if you do not take performance into account when designing many systems they will not scale when they need to, and suddenly you find yourself in real trouble.
Obfuscated code can be relative. Not everyone has the same understanding of the problem at hand, let alone the same level of skill. Many mathematical proofs escape my understanding, and look pretty obfuscated in their terse notation, but that doesn't mean they don't make perfect sense to the author and others. SQL can concisely represent complicated queries that are often not terribly readable, and understanding and analysing performance is an issue in almost every query you write. Just because you may not understand pointer arithmetic in C does not make it a bad and evil thing.
Some problems do not map well to the language they are written in - and you usually don't have the luxury of using or inventing or learning a better language for the problem. Other problems are just hard. Thus, the code may be complicated by necessity. Explaining what the code is trying to do might be complicated too - there's just no way around it sometimes, and over documenting doesn't help. Documentation can easily get stale and the meaning of words can be misinterpreted in ways straight code cannot.
Professors say these things, and they are good things to say to novices. But over time and with experience you know when to listen to them and when not to.
Isn't democracy great.
Gives just enough illusion of control to the people to keep them under control while the big end of town enjoys the spoils.
Of course, it means they have to pay for the licenses for the codecs.
Perhaps every sale even sends a little bit of money to M$.
Nice way to leverage the free cost of free software while at the same time selling out to proprietary interests and immoral anti-competitive laws like patents.
Although it was a one-off payment, they even got some money out of the Samba team. Novell are long gone. It seems they're the ones (proprietary interests) dictating the terms under which free software is now developed and used.
Yes, lets hide all those 'nasty details', like GNU and Linux being Free Software.
You wouldn't want users knowing they are actually allowed to modify or copy all of the software with no cost or legal problems. Lets hide all those details for those silly overweight four-eye geek types to worry about.
Absolutely disgraceful.
Your crap got old the first time anyone suggested it.
Just who the fuck do you think you are - anonymous coward - to tell people how to express their views?
A taste of what it could've been and what it might yet become?
Except America wasn't devoid of people when they landed.
Although there is nothing in this use of scanf that warrants that statement (in the pseudo code sense at least - like any other c function you need to check the return code). No different to using Int32.TryParse(string, out foo) and ignoring it's return code.
scanf used on integers can be perfectly safe. And any other input mechanism that read an integer would still fail with that loop - it has nothing to do with scanf. Like goto's, scanf is misunderstood and blindly called bad without understanding why - which is the problem, not the function(ality) itself. Anyone who doesn't understand their use enough to know when it is unsafe should not be calling for anyone who uses it to be fired.
Back on topic, I think money would be better spent on better programmers or training than only slightly useful tools which give you a false sense of security.
American sliced bread has a lot of sugar in it - it is very sweet, almost cake-like in its sweetness. Quite disgusting for what you use bread for. I started making my own bread while I was there because it was so sweet you couldn't eat it with savoury toppings like cheese or vegemite. And although some restaurants had italian or french bread I couldn't find it in the shops.
And strangely, it never seemed to go off, and was never fresh either - always in some half-state of slightly stale but never mouldy. Shit knows what else is in the stuff - must be full of preservatives they don't use here. It almost seems a stretch calling it bread at all.
Well one thing the distro's seem to have agreed upon - foistering bloated slow software on their users.
I tried to install Fedora and Ubuntu on an old laptop last weekend and had no end of frustration, and even after considerable tweaking the experience is far from perfect. This is a machine on which I easily developed 1000's of lines of code running emacs and netscape and gdb and evolution (ok it struggled a bit with all that at once, but only then).
The main problems are:
Actually - yes it is true. Almost every application would benefit from multi-threading to some extent.
You dismiss ui interactivity like it isn't important - but it is. But that isn't 'at best' at all. Also note that many gui toolkits have work-arounds so you don't need to use threads (i.e. io, timer events, etc) - but all these are are just threading anyway, and often harder to use and harder to debug than 'real' threads.
Lets look at a few common applications and see how threading helps them:
1. graphics applications. Using 4 cores to perform your blur filter is going to be faster than 1, and blocking the ui while you're doing it (or doing it in chunks and polling for new events is even slower).
1.1 viewing pictures. Threads can be used to easily pre-fetch and decode pictures before they are shown.
2. playing music. using a thread to play the music with a gui controller running separately will be easier to write and debug than using timout events and non-blocking i/o. Multiply the issue if you're playing and mixing multiple audio streams at once. Also note an os thread context switch is often going to be more efficient than a manual context switch (i.e. we have new data, lets re-load all of our state from where we were before, do the work, save our state manually because we've run out of work to do, return to the event loop, vs read data, process (our state is already 'here'), wait for more data) - so it might even use less total cpu time.
3. i/o bound applications. Using threads you can pre-fetch data in ways the operating system cannot (it will only pre-fetch linearly), and thus process with reduced latency and potentially reduced overall running time. Again you can do it with select/poll but often using a thread will be simpler to code and debug (a simple read loop vs register event, listen for event, process event, repeat).
4. business applications. threads can be pre-calculating results as you're using the ui, so you can improve the workflow of the user - e.g. so they don't have to hit a calculate button and wait for results. And many hard-to-calculate results can be calculated in parallel so you get your results faster.
5. online transaction processing. well processes probably work here as well as threads - but at some point things need to go through some thread-like mechanism. e.g. database access or filesystem access 'threaded' by the kernel.
6. web browsers. threads are essential here so your flash based adverts don't slow the rest of the application down too much. Again using threads is easier than polling.
In almost all non-trivial interactive applications threading can improve the user experience and reduce overall running time, while at the same time simplifying coding and debug (even on a single-cpu machine). It will also accelerate any parallel algorithm (on suitable hardware) and possibly simplify its code and debug as well.
Threads are not perfect but they are a practical solution to a real problem - how to get improved performance using modern hardware which is only increasing in its number of cores. So the opportunities in which threads increase performance will only increase. And auto-parellising languages/compilers will always be years away. There are real practical reasons java emphasises thread's so much - remember it was invented by a hardware manufacturer who knew where cpu's were going.
All interactive gui applications that do non-trivial work have to use threads - but they might not be using pthreads. Registering an event handler and callback and processing it, or doing a little bit of work at a time in an 'idle handler' is just a crude form of threading - one that has no debugger support and can be a total nightmare to debug. If there were 3 processing loops - a timeout, an idle handler (for say applying biz-wang filter on photoshop a few rows at a time), and handling user input, which do you think would be easier to debug. Using threads where you can view each thread's stack exactly where it is at a given point in time, or looking at some internal gui toolkit 'events pending' list which you may not even be able to see from the debugger in any form other than hex codes?
Actually misspelled is just another example of a grating Americanism. Like 'I could care less' which makes no literal sense in the places they insist on using it.
Misspelt is the correct English spelling, and shows up as correctly spelt in my editor (as does spelt, of course).
Yeah you're right, slashdot does need a WRONG moderation type.
In gtk+ everything is automatically laid out using layout managers. It makes absolutely zero difference to the application writer whether it is manual resize or not.
You have to explicitly override this behaviour and if you do you greatly increase your maintenance issues - e.g. now you have to manually account for different screen resolutions and font sizes rather than letting the system automatically size for you.
Not having resizable windows is just stupid - how can the same application run on a PDA screen and your dual-screen 24" machine at work without resizing?
Look, comparing ubuntu to windows is all well and good. It's what 'mainstream users' think computers are - windows.
But for fucks sake, don't use it as a reason to turn Ubuntu into windows! It's already losing it's "linux-ness" by being too newbie focussed.
Anyway - most of the 'problems' were with proprietary software. That is the fault of the proprietary vendors - how about laying blame where it belongs. A bare bones windows install doesn't even have half of those programs - she'd be pretty proper fucked on windows doing all those things if someone hadn't loaded her box with 'pirated' shit to start with. Some of the comments of the author indicate he doesn't really know what's going on either (e.g. using gimp to 'photoshop' a picture, and wondering why gimp isn't identical to photoshop. hint: it isn't photoshop).
Mental aid? But that is exactly the issue that literate programming addresses - so it would obviously be totally pointless for Knuth. Defining and communicating tasks in very small chunks is precisely what it is for.
Anyway - although i've had grand ideas to use unit tests and even written quite a few - in the end they've never actually been all that useful. Usually nobody but the original author uses them anyway because discipline is lacking, and what they test will usually show up pretty fast in other testing anyway.
It's a good idea, but like documentation it is usually to hard to keep them up to date - e.g. when you actually want the behaviour to change you have to go and fix all of the tests. Which actually means re-testing the tests. You spend more time maintaining your tests than writing the code, for very little practical benefit.
No it isn't.
That might be more 'literate', but it isn't 'literate programming' at all. Most of Knuth's code for example, which is the pre-eminent example of literate programming (he invented it) - uses minimalist variable names.
And FWIW if the second example was more realistic (i.e. just the variable name was abbreviated to d) I would find the it more readable - 'readability' is very subjective.
Its not a buffer overflow against a badly written C app.
It's just another exploit in yet another badly written C app.
Big Fucking Deal.
Writes cannot usually be performed asynchronously though - because they need to conform to the api presented. e.g. close() or sync() guarantee the data is written to non-volatile storage, whatever that may be. Being able to cache bits of the write in memory may help but at the end of the day it's all gotta be stored once close() returns, so it makes no real difference to many applications apart from being able to better store the data on disk. e.g. a compile writes files which are read by another programme later.
Also, your programme doesn't always have to block until the disk is finished - it just chooses to do so. There's nothing to stop your application using asynchronous i/o to load ahead of time what it needs. The kernel will already do some look ahead for sequential access, but you can certainly help it along by doing it manually. Many many algorithms can be modified this way - even many random access ones. Then there's things like b-trees (to minimise external accesses) and threads (to take advantage of any cycles otherwise being wasted). There's a reason Java throws so much at threads - its one way to get around the cpu/memory/disk impedance mismatch that is relatively easy to understand.
APIs are there to abstract away things like this on purpose (infact the whole system is geared for it - l1, l2 cache, main memory and virtual memory are all hidden to the application coder by default), so most programmers don't delve further, nor have the time to. They just assume a write or read will happen in fast-enough time and be done with it (or force the user to upgrade to faster equipment).
Even if disks get >> faster, they're sill << slower than main memory/cache, so the problem still remains - you're still only getting a limited amount of performance out of the system if you're software isn't smart enough (and the kernel can't do everything).
Hmmm.
You're a knob.