That's OK, you made me (and a number of moderators) laugh. The joke might have gone over one or two people's heads, but it was still worthwhile. Keep it up!
I think cities can be made to work, in some societies. But for whatever reason, they're definitely not the answer in the US.
Ah, but I think you're wrong there. They can be made to work in the US, but only by forcing people to stop running away from the problems that cities currently have and instead fix them. There are a number of aspects to sorting this out, but some of the main ones are to tax fuels much more highly (yes, this causes pain for people out in the suburban mega-sprawl, that's the point!), to plan on having a lot more public transport, to plan on having smaller stores more dispersed so that people don't have to drive a long way to the mall, and to not tolerate low-level crime even in poor areas. It's not easy, but it does work.
Some of these policies will hurt people living out in the real countryside (especially the fuel tax one) but the benefits overall are strong. A way of easing the pain for people who have to be in the countryside (e.g. farmers) is tax rebates, but these would have to be carefully designed to prevent massive abuse. (It's proved a tricky balance to get right in other countries, FWIW, but I suspect it is still the fairest way.)
I should note that living in a small and largely self-contained municipality of a few thousand is a perfectly acceptable response to the above policies; that's how a great many Europeans actually live, even though we have a lot of big cities too. I'd also like to point out that the US isn't the only place agonizing over these problems; I can remember them being a regular topic of debate here (the UK) at least as far back as my memories of such topics go (late '70s).
Better option: Become an expert at SQL and the language of your choice. I would choose something popular.
What, like the thousands of other identikit drones doing exactly the same thing?
But it's worse than that. While knowing about databases and transactions is a good thing (and has some really nice CS depth to it) just knowing how to hack up SQL isn't the same thing at all. It's a road to anonymous skill-less poverty, and a total waste of a higher education.
My advice is to always push yourself. Do the assignments and labs set, but don't just do that. Try to find the most elegant or the most "oh wow!" ways of solving things. Look at how other people solve problems and try to think for yourself why their solutions are good ones or bad. Got a problem? Try to solve it yourself first. Then ask for help, and try to solve it again for yourself after having had the help. Take as many different courses within CS as you can; you never know when you'll need what you learned in them. (Oh, and don't be tempted to plagiarize; if your tutors wanted someone random's solution off the 'net, they'd google it themselves, OK?) Last of all, pay at least some attention to what other disciplines are doing too; for example, I find the various physical sciences, standard engineering, business, contract law and psychology all to be relevant to the area of CS where I now work. The bigger and more diverse your skill-set, the easier it is to find a useful technique for a particular problem, and it's easier to learn principles and fundamental theories across a broad spectrum than it is to do the "SQL and Ruby" approach of just learning specifics across that spectrum...
But at the end of the day, if you can't develop software you're not a very useful computer scientist (aside from working at the uni).
Psst! Here's a big hint! You're not very much use at a uni either if you've got a CS degree and can't program. Without programming, all you can do is draw pretty flowcharts on a whiteboard, constructing castles in the air out of little more than hot air and dry-wipe markers. For all that to mean anything (including enough to be worth publishing!) it had better be programmed into something that approximates computing machinery.
Pure CS is just mathematical logic. The fact that we do things with this makes it an applied subject, and practitioners of applied subjects always get their hands dirty (well, metaphorically). If nothing else, trying to do things for real is a great source of interesting problems to work on.
Some of the concepts that CS text books explain in a chapter of verbal cruft could be better explained in three paragraphs of transparent analogy.
Alas, it's more often the case that you can use three paragraphs of transparent analogy to explain a concept and manage to completely miss the point and so totally mislead someone reading the text. Let's face it, some things are hard and must be experienced to be really understood. (See the Twelve Networking Truths for a good example.)
Wrong. Satellite links have terrible latency, and that's a killer (pun intended) for telesurgery. In reality, these sorts of advanced apps are handled by making the net non-neutral in a small area so that some packets get special treatment. After all, it doesn't actually matter if your web browser takes a few microseconds longer to load a page; you won't notice or care.
Anyone buying fancy network QoS for web browsing (or email or other non-critical stuff) has more money than sense, and it's the network owner's duty to correct that imbalance...
OK, there's a good argument that everyone's email or web traffic ought to be the same, but for some applications you really do want the net itself to not be totally neutral. For example telesurgery, where a surgeon conducts operations remotely through the use of a robot, and where you really don't want packets getting delayed and are willing to pay for the elevated service. Do we really want such applications blocked (or made unreasonably hazardous) just because of poorly written regulations that are attempting to prevent possible future abuse? Would it not be better to break up the big telco monopolies instead and so allow competition to work in customers' favour?
On a single core without hyperthreading, your best bet (if you can) is to write very efficient single-threaded code, using non-blocking I/O as much as possible. Some language runtimes require the use of lots of threads even on single-core systems, but that's horrible.
Once you've got multiple cores, getting multiple threads of execution (either in multiple processes or in multiple threads) makes a lot of sense. I believe hyperthreading benefits particularly such code that has multiple threads executing in the same bit of code since the parallelism there is within a memory management domain, so OpenMP is better there than pthreads, and pthreads is (probably) better than processes. On the other hand, if you're potentially working across a cluster (cue the beowulf jokes!) your code had better be written with processes (and probably MPI) in mind. Of course if you're going that way, you also ought to spend on getting a good interconnect network...
All in all, getting proper high performance is tricky. The best guide to making things go faster is to try to reduce the amount of shared state between threads-of-execution. Reducing shared state also helps to make the code easier to debug. (Alas, dealing with the bits of state that must be shared is what makes life hard.)
In the world of anal retentive ACLs, Stack Dumps, tedious reports, and just plain dumb users, who wouldn't want to just occasionally fantasize about swinging around a 6' sword and lopping someone's head off, or blasting someone into charred oblivion?
Fantasize? Who said anything about only fantasizing about them?
There are european diesel cars that match the fuel efficiency of equivalent petrol (gasolene) hybrids in that situation
A real datapoint: I've got a diesel car that's a few years old (i.e. not the latest engine generation) and I get about 50mpg (US measures; that's 60 in UK measures) in real urban-cycle driving in a hilly city. Your Mileage May Vary, of course, but that's some for-real figures. (This is a good thing since diesel is about $6.75/gal after unit conversion, and gasolene is only a few percent cheaper.)
If it were hidden, you'd be doing something completely unlikely and suddenly and unexpectedly get to Slashdot, like pressing Ctrl+Alt+/, then Shift+Meta+., then double clicking on the "Help" menu item.
Damn, time to change the keybindings on my apps to something less obvious.
... there is real mass transit so that companies don't have to invest money in doing this for themselves. This leads me to ask a few rhetorical questions: How long before Google gets together with some of the other tech companies in the area to run a shared service? How long after that before it transforms into the sort of mass transit service that people elsewhere in the world take for granted?
Welcome to the consequences of high-density living.
The only reason ARM/MIPS/SH3 CPUs in PDAs and cell phones have lower power specs than mobile x86 CPUs, is because they omit the MMU, FPU, etc. etc. Once you start trying to run REAL software on those CPUs, you find the 400MHz ARM CPU runs worse than the 200MHz Pentium CPU you had 10 years ago, which had similarly low power requirements...
Luckily, most of the time you're not doing that sort of thing; indeed, most of the time these small machines will be doing nothing at all (other than waiting for you to interact with it). You don't run full video editing suites or heavy CFD codes on a handheld!
Did they fix the horrible fork performance on OS X yet?
The easiest workaround (if you can) is to use vfork() instead of fork(). As I understand it, this is an acceptable alternative if you only fork() shortly before doing an execve() (or one of the related library calls) which is by far the most common case.
It's lower than that in some EU countries (including mine); I think the minimum permitted value is actually 15%. The Germans want the minimum increased to (their level of) 19%, but other countries are resisting. Luckily, the minimum VAT level isn't a majority-vote topic, so the chances of anything changing soon on it are minimal.
foreigners can often get a refund for that (not sure how that works)
If I remember right (and it's a long time) you keep the receipts and take them to a special office at an exit port (either in the airport or often on board the ship if you're leaving by sea).
Now if only stores in the USA (particularly ones you visit in person) would state the price you pay up front, so that I can figure out whether to go to an ATM first (I'm not keen on paying with plastic; my bank already knows more about me than I like). State the other prices too if you want, but don't assume I know the local total sales tax rate, OK? And don't give me any BS about "but the rate may be varied at short notice"; other places can cope easily enough, so you can too.
The kings of the sorting hill are quicksort, heapsort, mergesort, and insertion sort. For real data, quicksort (especially with a good pivot selector sub-algorithm) and heapsort are fastest (heapsort is also very frugal with the stack). Mergesort is a bit slower (but still O(n log n) with reasonable factors) and has the major bonus of being stable, so that elements that are equal to each other are not reordered (and that's very useful indeed with real data). Insertion sort (also stable) is the only O(n2) algorithm worth considering, and then only in a special case: when you've got some sorted data and want to add an item to it, this being a case that comes up surprisingly often. Insertion sort is also really easy to implement correctly.
Radix sorts are reasonable, but only if the input keys are fairly short. I've never had data like that myself; for 10 character strings, a good quicksort is theoretically better for lists of a million keys or so, which is pretty good.;-) Also, C programmers should definitely prefer to use quicksort, of course, because they've got an implementation of it in libc...
The problem with caching is that most of the sites out there use dynamic content.
But most data is still static (images, stylesheets, external javascript, video, pdfs, etc.) including most of the stuff that's actually high bandwidth, and all of that can be cached (both in your browser and in proxies) quite nicely. That's the way HTTP is designed to work. So, looking at the/. front page, I see that the dynamic content is around 19kB while the cacheable content is more than that in total.
As a web designer, you should take care to ensure that as much of content is static as possible (you can do a lot with stylesheets and javascript to make the page appear more dynamic than it really is) with the added benefit of making everything look much slicker for repeat visitors. (Indeed, as far as I can see the real problem is the convoluted mess caused by ad servers that seem to insist on trying to both defeat caching and asynchronous page loading, but that's another tale...)
Slashdot Mirror
That's OK, you made me (and a number of moderators) laugh. The joke might have gone over one or two people's heads, but it was still worthwhile. Keep it up!
Some of these policies will hurt people living out in the real countryside (especially the fuel tax one) but the benefits overall are strong. A way of easing the pain for people who have to be in the countryside (e.g. farmers) is tax rebates, but these would have to be carefully designed to prevent massive abuse. (It's proved a tricky balance to get right in other countries, FWIW, but I suspect it is still the fairest way.)
I should note that living in a small and largely self-contained municipality of a few thousand is a perfectly acceptable response to the above policies; that's how a great many Europeans actually live, even though we have a lot of big cities too. I'd also like to point out that the US isn't the only place agonizing over these problems; I can remember them being a regular topic of debate here (the UK) at least as far back as my memories of such topics go (late '70s).
But it's worse than that. While knowing about databases and transactions is a good thing (and has some really nice CS depth to it) just knowing how to hack up SQL isn't the same thing at all. It's a road to anonymous skill-less poverty, and a total waste of a higher education.
My advice is to always push yourself. Do the assignments and labs set, but don't just do that. Try to find the most elegant or the most "oh wow!" ways of solving things. Look at how other people solve problems and try to think for yourself why their solutions are good ones or bad. Got a problem? Try to solve it yourself first. Then ask for help, and try to solve it again for yourself after having had the help. Take as many different courses within CS as you can; you never know when you'll need what you learned in them. (Oh, and don't be tempted to plagiarize; if your tutors wanted someone random's solution off the 'net, they'd google it themselves, OK?) Last of all, pay at least some attention to what other disciplines are doing too; for example, I find the various physical sciences, standard engineering, business, contract law and psychology all to be relevant to the area of CS where I now work. The bigger and more diverse your skill-set, the easier it is to find a useful technique for a particular problem, and it's easier to learn principles and fundamental theories across a broad spectrum than it is to do the "SQL and Ruby" approach of just learning specifics across that spectrum...
Pure CS is just mathematical logic. The fact that we do things with this makes it an applied subject, and practitioners of applied subjects always get their hands dirty (well, metaphorically). If nothing else, trying to do things for real is a great source of interesting problems to work on.
Wrong. Satellite links have terrible latency, and that's a killer (pun intended) for telesurgery. In reality, these sorts of advanced apps are handled by making the net non-neutral in a small area so that some packets get special treatment. After all, it doesn't actually matter if your web browser takes a few microseconds longer to load a page; you won't notice or care.
Anyone buying fancy network QoS for web browsing (or email or other non-critical stuff) has more money than sense, and it's the network owner's duty to correct that imbalance...
OK, there's a good argument that everyone's email or web traffic ought to be the same, but for some applications you really do want the net itself to not be totally neutral. For example telesurgery, where a surgeon conducts operations remotely through the use of a robot, and where you really don't want packets getting delayed and are willing to pay for the elevated service. Do we really want such applications blocked (or made unreasonably hazardous) just because of poorly written regulations that are attempting to prevent possible future abuse? Would it not be better to break up the big telco monopolies instead and so allow competition to work in customers' favour?
On a single core without hyperthreading, your best bet (if you can) is to write very efficient single-threaded code, using non-blocking I/O as much as possible. Some language runtimes require the use of lots of threads even on single-core systems, but that's horrible.
Once you've got multiple cores, getting multiple threads of execution (either in multiple processes or in multiple threads) makes a lot of sense. I believe hyperthreading benefits particularly such code that has multiple threads executing in the same bit of code since the parallelism there is within a memory management domain, so OpenMP is better there than pthreads, and pthreads is (probably) better than processes. On the other hand, if you're potentially working across a cluster (cue the beowulf jokes!) your code had better be written with processes (and probably MPI) in mind. Of course if you're going that way, you also ought to spend on getting a good interconnect network...
All in all, getting proper high performance is tricky. The best guide to making things go faster is to try to reduce the amount of shared state between threads-of-execution. Reducing shared state also helps to make the code easier to debug. (Alas, dealing with the bits of state that must be shared is what makes life hard.)
I must've maxed out my productivity then...
Damn, time to change the keybindings on my apps to something less obvious.
... there is real mass transit so that companies don't have to invest money in doing this for themselves. This leads me to ask a few rhetorical questions: How long before Google gets together with some of the other tech companies in the area to run a shared service? How long after that before it transforms into the sort of mass transit service that people elsewhere in the world take for granted?
Welcome to the consequences of high-density living.
http://slashdot.org/~tomstdenis/friends/ says otherwise, at least at time of writing...
Hmm, that sounds very much like "Mad (Dark Side of the) Force Powers" to me.
Use git for congresscritters...
That's an alias for:
* Yes
That's simple. An ounce weighs many times more than a pound. HTH!
It's lower than that in some EU countries (including mine); I think the minimum permitted value is actually 15%. The Germans want the minimum increased to (their level of) 19%, but other countries are resisting. Luckily, the minimum VAT level isn't a majority-vote topic, so the chances of anything changing soon on it are minimal.
Now if only stores in the USA (particularly ones you visit in person) would state the price you pay up front, so that I can figure out whether to go to an ATM first (I'm not keen on paying with plastic; my bank already knows more about me than I like). State the other prices too if you want, but don't assume I know the local total sales tax rate, OK? And don't give me any BS about "but the rate may be varied at short notice"; other places can cope easily enough, so you can too.
The kings of the sorting hill are quicksort, heapsort, mergesort, and insertion sort. For real data, quicksort (especially with a good pivot selector sub-algorithm) and heapsort are fastest (heapsort is also very frugal with the stack). Mergesort is a bit slower (but still O(n log n) with reasonable factors) and has the major bonus of being stable, so that elements that are equal to each other are not reordered (and that's very useful indeed with real data). Insertion sort (also stable) is the only O(n2) algorithm worth considering, and then only in a special case: when you've got some sorted data and want to add an item to it, this being a case that comes up surprisingly often. Insertion sort is also really easy to implement correctly.
;-) Also, C programmers should definitely prefer to use quicksort, of course, because they've got an implementation of it in libc...
Radix sorts are reasonable, but only if the input keys are fairly short. I've never had data like that myself; for 10 character strings, a good quicksort is theoretically better for lists of a million keys or so, which is pretty good.
As a web designer, you should take care to ensure that as much of content is static as possible (you can do a lot with stylesheets and javascript to make the page appear more dynamic than it really is) with the added benefit of making everything look much slicker for repeat visitors. (Indeed, as far as I can see the real problem is the convoluted mess caused by ad servers that seem to insist on trying to both defeat caching and asynchronous page loading, but that's another tale...)