Scanners, photocopiers and printers already (so I understand) refuse to scan/copy/print images containing the eurion constellation.
If DRM'd images were displayed with a similar type of watermarking, which digital cameras could detect, then that could close off taking photos. (Screenshots themselves won't be possible with the DRM operating system in control - the DRM'd content won't display on screen with an app capable of taking a screenshot).
OK, so you could get away with film (you might need to do your own processing), but good luck digitising it. I guess you might be able to retype any text, though.
Given how quietly the eurion constellation was deployed, I wonder when we'd know if a similar blocking pattern is interpreted by digital cameras?
To help address the underlying problem which the blog points out I've written a tool called Exmap.
It uses a loadable kernel module to work out which pages are really shared between which processes, to provide some accurate numbers on memory usage in the face of complications such as demand-paging and copy-on-write.
It isn't intended to analyse the memory usage of a specific process so much as a system of processes using shared libs/mmap'd files. In particular it doesn't do any heap analysis (for that you probably want valgrind/massif or memprof).
But if you've got many processes running which use shared libs, this can help you work out your "real" memory usage. It'll also help you look at the usage of individual ELF sections and (if you're running non-stripped binaries) symbols.
It currently has some rough edges (e.g. no 64-bit support, some problems on pre-linked systems), sorry about that.
The closest I've come to dealing with it was writing exmap.
This is a (moderatly ugly) gtk+ tool which uses a loadable kernel module to work out which pages are used by more than one process. If a page is used by N processes, each process is credited with PAGE_SIZE/N bytes.
I believe it "solves" the problem you describe above. The biggest problem is that it provides a little too much information, so perhaps I should simplify it a bit.
(Known problems with current 0.8 version: some of the tests fail intermittently and some systems with pre-linked elf binaries can cause errors. Should fix up both with the next release).
Personally, I wouldn't actually purchase the X pieces a month, instead just put the money away. Component prices are still on a general downwards trend, so buying everything at the last moment will generall get you a better deal.
This is assuming that you can't make use of the new components in some other way before you have them all.
On the quietness front, I bought an Antec Sonata case (has a big, variable speed case fan, nice rubber mountings for the hard drives and generally good build quality) and was pleased with the low noise of the case fan. Now...if only I had spent money on a quieter CPU cooler.
Both effects would exist. This is clearly seen by postulating gas at $100/gallon. "soft" usage of gas would almost completely stop, "essential" usage would continue, passing on the cost down the supply chain as you say.
So I'd say that I disagree with your initial "No". A bit of thinking would show that in general increasing the price of something for which people have *some* discretionary use will decrease the overall usage of it (modulo second order effects where more people start to buy because the higher priced item aquires a cachet it didn't have before. I don't see that applying to gas.)
The practicalities of the matter depend on details such as how much of a price increase is made and how much people perceive their use to be discretionary. i.e. a 5 cent hike is unlikely to have a perceivable effect.
Whether $3-4 dollars is sufficient to have a noticeable effect would, I suspect, be determined by how much choice the people paying it feel they have. ("Got to get to work, have to pay forgas", versus "I'll have to visit my friend 200-miles away every 4 weeks instead of every 2 weeks". The big effect will come where people make the mental switch "hmm...I could save myself $X dollars/week by cycling, a cycle costs $4X and I can save on my gym membership.).
And, like it or not, raising the cost of gas improves the practicality of the alternatives (again, simple economics). This is the effect our children will see (not controversial - the controversial question is whether we will see it) when gas is sufficiently expensive (due to limited supply) and the much-despised alternative energy sources and more efficient forms of transport transport become no-brainer choices.
Hybrids are at a break-even at the moment (what a surprise! a single supplier pricing things so that they get the benefit, not the consumer) but the long-term trend is oil prices upwards, so the economics of the hybrid are only going to get better. That'll scale up the production of these things (and other alternatives) and push the economics of owning one over the tipping point (as will competition to supply them).
Basically, for a guaranteed win, invest in a portfolio of companies providing this sort of technology. Of course, apart from picking the winners, your main problem is knowing how quickly this trend will play out. [Unless someone invents an efficient way to make gas from sunlight, water and CO2. That'd be a good thing to invest in.]
I don't think you can really do what you describe. This sort of thing is all about problem solving, the detective work you do to find the cause (and then solution) when you are having some problem. If you know the answer to begin with, you can't go through the process.
If your ultimate goal is to learn more about networking, then I'd say you can learn a lot by running a network analyser (ethereal is a very good gui tool which understand a lot of protocols. It can also read tcpdump files, which is handy).
Look at the traffic on your network. Do you understand all of it (if not, go and read up)? Now reboot one of your boxes. Can you pick out the boot sequence traffic? Did any of it surprise you? Read some more.
Ideally, get a heterogenous network going. Stick a windows box on there. Repeat the above questions.
Set up some local file sharing protocols (e.g., samba, nfs, webdav) and shares. Watch the traffic. You'll see authorisation protocols in there now too.
Until something goes wrong, I'd say this is the best way to learn. There is a lot of detail in these protocols. And additionally, the best way to quickly fix a network when it is broken is to know what it looks like when it is running normally, which is something you have to do beforehand.
Last top tips:
- network problems are much easier to diagnose with 3 boxes. Given the problem "A and B can't talk X (or are very slow talking X)" there is a lot of trouble to shoot. Reducing that to "A and B can't talk X, but A and C can. Hmmm...and B and C can't" narrows the field quite a lot.
- always check the basics first. Things get more complex (and take longer to analyse) as you head up the network stack, so check the lowest layers first. Which are the lowest layers? Go and read a book on TCP/IP and always remember that the lowest layer is physical, so always check its plugged in...
Have you played guild wars? Its exactly what you want. The PvP is all tactics, with all PvPers being levelled to the same. There is some dependence on which skills and items you have "unlocked", but that isn't the main thrust of things. Success is about how your chosen character skills operate together and interact with those of your team. And of course how well you and your team mates do at using those char skills.
Also, no monthly fee (since most areas are instanced in a peer-to-peer way, with little server load, so ArenaNet's running costs are lower).
Sorry to sound like an advert, but it is a fun game and appears to fit what you are looking for. (Hmm...maybe *you* are the guild wars plant...asking that question to entice a positive response about the game. Damn, you're subtle).
Different processes generally do run on different cores, on most multiprocess OSs I know of.
Child processes are related to the parent process (they have a parent-child relationship, the parent can pass some shared information into the child).
A greater degree of sharing (e.g. a shared memory space) is exactly what an (OS-level) thread is...a seperate, schedulable execution context which shares a memory space with its parent.
You're right in the pthreads API isn't the nicest one to work with. But in my experience that isn't the main problem with threading. The main problem with threading is that by default *everything* is shared. All the dirty little global, file scope and static variables in all the little libraries your app loads to get things done. And any write access to such shared data by multiple threads without appropriate locking is quite likely to be a hard-to-reproduce-and-find fault waiting to happen.
But your new API doesn't make much sense to me. Your additional parameter to 'exec' isn't about threading, in that you've specified an exe name. If you're creating another thread, you'd be in the same exe as the one executing the call - thats a redundant parameter.
The nearest thing to what you suggest would be a new parameter to fork() which shared the VM between the two processes. Funnily enough thats pretty much what fork() is implemented on top of in Linux. Underneath it all there is a 'clone()' system call which is used to create a new execution context. The flags to clone() determine how much is shared between the parent and child. If you share VM, you get something close to a new thread, if you don't, you get something close to a new process.
[The 'something close' is in there to guard against any pedants pointing out that if you are so inclined you can specify odd combinations of CLONE_ flags and get some weird entities which don't correspond to traditional threads or processes.]
See 'man clone' on a Linux box for details of a library level clone function built on top of the clone syscall.
But on the face of it, using clone() to create a thread isn't too different from a plain pthread_create(). And that doesn't get you too far, because you then need some locking mechanisms. All of a sudden you're adding API for mutexes, semaphores, condition variables and all that guff. And then you're back with something as unpleasant as the pthreads API. Well actually, you're not. Because that API does suck pretty hard.
Basically threading is something which probably benefits from language-level support. Java (and I assume C# and probably others) have some of this. But that doesn't help game developers who I assume will be writing their performance critical code in something a bit closer to the metal.
Without much effort on your part you could grab DrScheme (its packaged as part of some Linux distros, otherwise go to here. That's your graphical coding environment. It runs on Windows, Mac and Linux.
For material to accompany it, "How to Design Programs" is a good book available online in its entirety here.
If you're more hardcore, then you might prefer "The Structure and Interpretation of Computer Programs", another book online here. SICP also has about 20 hour-long downloadable lecture videos, but be prepared for 70/80s fashions in the audience...
I think HTDP is a great way to learn to program in general, and DrScheme is a good environment in which to learn.
Downsides: scheme isn't widely used outside of education. It is also not obviously closely related to mainstream languages (C++/Java/C#/Perl/Python/Ruby) in appearance.
Upsides: scheme is fairly easy to learn, so you can focus on picking up concepts and discovering if you enjoy programming. Scheme is a also a very close relative to lisp, which is a (slightly:-) more pragmatic language to learn to deploy applications in.
Exactly. This seems so obvious to me too. You need:
- a display - an input device (at least voice, probably written too assuming voice recognition doesn't do away with it) - some processing power - some storage - networking (gsm, wifi, etc)
The only (technical) reasons to bundle more than one of these in the same package is to reduce overall form factor or to provide a wired pathway for bandwidth/security reasons.
We've got bluetooth headsets, we're able to plug usb stick/flash storage into things. What would it take to have a wirelessly-accessible hard drive in your backpack/jacket pocket?
And of course, the real payoff here is that you have your portable versions of all of these things, but you should be able to walk up to and use and "public" devices (e.g. large screen, full size keyboard) and have them automagically work with your programs, your data, your network, etc.
Kind of like the PC architecture have standard components and busses (ISA/PCI/etc). Manafacturers can manafacture to the interconnection spec, reducing the O(n^2) interoperability problem to O(n).
So...what would it take? A "bodybus" specification? PCI-over-wifi?
Ah, thanks for that. That seems to make more sense.
It does leave the question as to what people were thinking when they thought a post-fusion model the best explanation, but "thats not important right now".
Following this story, I was thinking about this gravitational collapse thing this morning.
It seems odd to me that falling matter can bounce back into a big explosion under gravitational power. Naively, you'd expect it to bounce back to the same "height". I guess some/most of the matter is staying at a lower potential energy, so that a small amount can be ejected with a large amount of energy?
Could you or anyone else give me a hint as to what I'm missing here? If it is the above scenario (most matter staying 'low'), could a similar effect be achieved on a smaller scale, in (a zero-g) lab (by allowing some fluid to collapse in on itself?).
will check out a repository, tunnelled over ssh. No need to run a subversion server to do that.
One of the nice things about subversion (recently converted user, very happy so far) is the support for multiple url formats and communications methods.
Another notable thing (for windows users) is TortoiseSVN, (an explorer shell extension) which is just great.
I can see how the distributed, multi-repo model of bitkeeper/darcs/arch is superior but svn looks good if you only need single-repo.
Also, bitkeeper has some powerful gui tools (and probably the kitchen sink too). Haven't really used arch/darcs.
But be careful. If you know (because of knowledge of the problem domain) that N will be 50 for the next few years, there is no shame in a linear pass to find your entry.
Adding a code to maintain a sorted list and perform a binary search or adding hashing, all so you can scale nicely to N=1,000,000 kind of misses the point.
I think my point is that dumb algorithms are fine first implementations. Don't waste your time with a "better" algo if the problem doesn't demand it. (And how do you know the problem demands it? Well, really you should use profiling again, rather than "I may have lots of these").
EE Smith's "Lensman" series. Never has space opera been so much fun, or weapons systems built up to such ludicrous extremes. Good descriptions of large-scale engagements in space too (aha...I shall attack in theoretically-optimal cone formation! Hmmm....I shall shift my cone into a cylinder, with 10 layers of defense-only drone ships at the end and cut out the power-centre at the apex of your cone formation! Mwahahaha)
I really liked the way each generations "ultimate weapon" is trumped by the next...
Towards the end it is "no mobile craft can asault these fixed-placement weaponry" followed by "lets render entire planets inertialess and use those as ultimately powerful bases".
So how do you defend against unstoppable planets? Why...the sunbeam of course.
Get a copy of K&R ANSI C (is there a C89/99 version now?). Read all the way through it and do those of the exercises which interest you.
C is a small language. The C standard library is small (and more importantly, it is *standard* and cross platform). It is both easy to learn and hard-core. It is also one way towards learning the "industry standard" C++ (some would argue that you shouldn't start from C, but as long as you don't develop too many bad habits I think its OK).
The biggest problem is that C allows lots of "bad habits". This can be mitigated by reading some coding style guidelines (I'd recommend the 'CodingStyle' document in the linux kernel source documentation, but others may recommend the GNU standards).
You can easily manipulate files and produce console (stdin/stdout/stderr) based code without calling any operating system specific APIs. (fopen/fclose etc are C standard, open(), close() are Unix/Posix).
I personally write two programs to learn a new language/environment: a hex dumper and an implemenetation of the "sieve of eratosthenes" for finding primes. Between the two of them you get to deal with various data types and conversions, file and screen I/O and you've got enough functionality to make it worth structuring a little (pulling out functions/methods), so you end up learning useful stuff.
If you want to get into GUI coding, you're going to have to pick a GUI toolkit. Those *are* daunting. Don't try and do the cross-platform thing to start with. Hitch yourself to GNOME or KDE and get going.
But if it were me[*], I'd do the above to get my basics straight and then try and find a project of interest. The nice thing about contributing to an existing project is that the hard work of infrastructure is aleady there (someone else has set up the makefiles, etc etc). The downside is that you need to learn how to fit your work in with someone else modus operandum. This last is more a social than technical issue, but hey, that is your current core competency right?
Good luck. Go and do it, keep a diary then post a "here is how I got on" story in a few months. That should give you something to aim for, too.
[*] it kind of is me, except I'm about two years younger and switched back to a dev post a couple of years back after several years as a sys/net-admin and consultant.
The comment from Linus isn't about using estoppel as a sword.
LT notes that his comments in COPYING allow *someone else* to know that they have the shield of estoppel on this matter.
i.e. he is saying that he isn't modifying the GPL per se, but anyone with a lawyer would be able to read the comments in the COPYING file and have confidence that they could link+distribute their non-derived works (binary modules) with the kernel (since they could have a reasonable expectation of estoppel).
There are some good threads (no links, too lazy) on this in the LKML archives. In particular, Linus's views on what constitutes a derived work I found interesting.
re: lawyers copying copyrighted contracts, the fact that an act is commonplace doesn't make it legal. (It may be legal for other reasons, e.g. fair use, but I don't think your point stands). Witness speeding (in the UK) and sharing MP3s. Whether that makes it harder to get a prosecution, I wouldn't know.
All the "max bandwidth" figures you see are for streaming reads, where the disk heads move (relatively) smoothly along logically continguous chunks of disk.
Compare that to copying from one part of the disk to another. Your 100Mbyte file will be copied in chunks. The sequence of events will go something like this at a low level:
while( data left to copy ) {
move disk heads to offset in file to be read
read a chunk
move disk heads to offset in file to be written
write a chunk }
The bit that really costs you is the two seeks. For a disk with an advertised seek time of 10ms, you are paying 20ms per chunk on top of your read+write times.
20ms/chunk == 50 chunks/second. So, 5Mbytes/second would be 100Kbytes/chunk, (assuming the actual read+write are free). [If you meant 5Mbits a second that would be ~12Kbytes/chunk.]
If you had two disks (on different disk controllers, etc etc). The disk heads wouldn't need to seek around much at all, and you'd get much closer to the theoretical bandwidth.
Or if you have a RAMdisk (and enough RAM), you could try:
cp bob/file to RAMDISK/file cp RAMDISK/file fred/file
which should also run at full speed.
Also - note that if you do any other task which involves reading or writing to the disk at the same time, you'll hurt performance even more.
Its not the case that "time taken to perform tasks A and B in parallel" == "time taken to perform task A + time taken to perform task B", you also pay the cost of switching between them, which is comparitively steep in the case of disk I/O.
I think we are in agreement. Your nationality (a political concept) is British.
But as an inhabitant of the geographical region of the island of Britain, I am a Briton/British person. This happens to be the same as my nationality, but it needn't be. I am also geographically an English person. Its a multiple-value thing. Ditto I am a European person (I guess both geographically and politically).
My point of interest is whether *geographically* inhabitants of Northern Ireland might consider themselves as Irish people. I thought they might, but also (quiet reasonably) the question is so charged with political overtones that some might not want to do so.
(Its quite similar to the way Canadians and inhabitants of the USA are both North Americans. A person born in Canada is Canadian by nationality, and is geographically also a Canadian, a North American and I guess a Western Hemi-spherian).
I'm beating this horse to death because there is huge overlap (and hence misunderstanding) regarding these two terminologies, and I'm interested in people communicating effectively (especially when they are disagreeing/discussing things). I'm also interested to get a larger sample of N. Irish people to answer this particular question:-)
Your way of avoiding confusion seems very pragmatic...
There is a geographical entity known as the British Isles, consisting of a large island called Britain, a slightly smaller island called Ireland and a number of significantly smaller islands (Isle of Man, Isle of Wight, etc).
Geographically, one might call an inhabitant of Britain a Briton (or British person) and an inhabitant of Ireland an Irish person (don't know of an equivalent noun).
The reason this is sensitive is that the political arrangements do not follow geographical lines and I'm not going to touch the topic of whether they should or not.
I suppose one might be able to call both of these inhabitants British (due to their living in the British Isles) but that seems overly antagonistic to those living in the country of Eire (a country which covers the majority of the geographical entity of Ireland) and certainly doesn't follow common usage.
Politically, I think people use "British" as a nationality to identify with "being a citizen of the UK" and "Irish" to identify "being a citizen of Eire".
I might imagine (but would not wish to presume) that an inhabitant of Northen Island (a region of the UK which lies in the island of Ireland) might describe themselves as both British (nationally) and Irish (geographically).
I think there is a lot of confusion on these issues, and I welcome corrections and clarify on this terminology.
As to being in Europe, I think it depends on the rotating European presidency. Whilst Berlusconi is EU president I think we're not:-)
Sure. I was commenting on the tangent regarding the number of worldwide mail domains.
Howver, 100k is also a low estimate for hosts.
In 2001, Dan Bernstein did this survey which yields an internet-wide estimate of 4 million reachable IP addresses running an SMTP server. I doubt the figure has decreased.
Scalability over many orders of magnitude is a fairly key requirement for internet protocol design.
I think 100k mail domains worldwide is a little on the low side. One ISP to my knowledge hosts over 30k mail domains. Of course, that could just be our cool software:-)
> So... your security model breaks utterly as soon > as someone finds a bug in the *compiler*?
The bugginess (or otherwise) isn't the main issue. You can think of the checks done in the compiler regarding access permissions as equivalent to the checks done by the system call interface at run time (and by the page fault handler, etc). If either is buggy (e.g. the recent mremap() bug in the Linux kernel) you get privilege escalation (of course, such checks are particularly difficult at compile time for some languages, e.g. anything with real pointers).
Basically the system comes down to transitive trust. The kernel could assume trust in one (or more) compilers, such that it is happy running the output of those compilers without run-time checks.
Note:
1 - You could have multiple trusted compilers, for whichever languages you favour.
2 - You don't need to enforce your trust relationships via digital signatures (although that would be one way). One alternative method would be to allow only "trusted" processes to mark another process as executable. Then, compilers would mark their output as executable.
3 - Other processes could run, but in a run-time sandbox (own address space, system call checking etc)
4 - Oops. Look at what we've got. Unix. "trusted" == root, except that system calls made by root owned processes would bypass all run-time checks.
OK, so that isn't a perfect view of things (it is useful to have run-time checking on most/many root processes), but you could certainly envisage a new capability which allowed a process to run in the kernel address space?
Slashdot Mirror
Just had an interesting thought.
Scanners, photocopiers and printers already (so I understand) refuse to scan/copy/print images containing the eurion constellation.
If DRM'd images were displayed with a similar type of watermarking, which digital cameras could detect, then that could close off taking photos. (Screenshots themselves won't be possible with the DRM operating system in control - the DRM'd content won't display on screen with an app capable of taking a screenshot).
OK, so you could get away with film (you might need to do your own processing), but good luck digitising it. I guess you might be able to retype any text, though.
Given how quietly the eurion constellation was deployed, I wonder when we'd know if a similar blocking pattern is interpreted by digital cameras?
(shameless plug)
To help address the underlying problem which the blog points out I've written a tool called Exmap.
It uses a loadable kernel module to work out which pages are really shared between which processes, to provide some accurate numbers on memory usage in the face of complications such as demand-paging and copy-on-write.
It isn't intended to analyse the memory usage of a specific process so much as a system of processes using shared libs/mmap'd files. In particular it doesn't do any heap analysis (for that you probably want valgrind/massif or memprof).
But if you've got many processes running which use shared libs, this can help you work out your "real" memory usage. It'll also help you look at the usage of individual ELF sections and (if you're running non-stripped binaries) symbols.
It currently has some rough edges (e.g. no 64-bit support, some problems on pre-linked systems), sorry about that.
The closest I've come to dealing with it was writing exmap.
This is a (moderatly ugly) gtk+ tool which uses a loadable kernel module to work out which pages are used by more than one process. If a page is used by N processes, each process is credited with PAGE_SIZE/N bytes.
I believe it "solves" the problem you describe above. The biggest problem is that it provides a little too much information, so perhaps I should simplify it a bit.
(Known problems with current 0.8 version: some of the tests fail intermittently and some systems with pre-linked elf binaries can cause errors. Should fix up both with the next release).
Personally, I wouldn't actually purchase the X pieces a month, instead just put the money away. Component prices are still on a general downwards trend, so buying everything at the last moment will generall get you a better deal.
This is assuming that you can't make use of the new components in some other way before you have them all.
On the quietness front, I bought an Antec Sonata case (has a big, variable speed case fan, nice rubber mountings for the hard drives and generally good build quality) and was pleased with the low noise of the case fan. Now...if only I had spent money on a quieter CPU cooler.
Both effects would exist. This is clearly seen by postulating gas at $100/gallon. "soft" usage of gas would almost completely stop, "essential" usage would continue, passing on the cost down the supply chain as you say.
So I'd say that I disagree with your initial "No". A bit of thinking would show that in general increasing the price of something for which people have *some* discretionary use will decrease the overall usage of it (modulo second order effects where more people start to buy because the higher priced item aquires a cachet it didn't have before. I don't see that applying to gas.)
The practicalities of the matter depend on details such as how much of a price increase is made and how much people perceive their use to be discretionary. i.e. a 5 cent hike is unlikely to have a perceivable effect.
Whether $3-4 dollars is sufficient to have a noticeable effect would, I suspect, be determined by how much choice the people paying it feel they have. ("Got to get to work, have to pay forgas", versus "I'll have to visit my friend 200-miles away every 4 weeks instead of every 2 weeks". The big effect will come where people make the mental switch "hmm...I could save myself $X dollars/week by cycling, a cycle costs $4X and I can save on my gym membership.).
And, like it or not, raising the cost of gas improves the practicality of the alternatives (again, simple economics). This is the effect our children will see (not controversial - the controversial question is whether we will see it) when gas is sufficiently expensive (due to limited supply) and the much-despised alternative energy sources and more efficient forms of transport transport become no-brainer choices.
Hybrids are at a break-even at the moment (what a surprise! a single supplier pricing things so that they get the benefit, not the consumer) but the long-term trend is oil prices upwards, so the economics of the hybrid are only going to get better. That'll scale up the production of these things (and other alternatives) and push the economics of owning one over the tipping point (as will competition to supply them).
Basically, for a guaranteed win, invest in a portfolio of companies providing this sort of technology. Of course, apart from picking the winners, your main problem is knowing how quickly this trend will play out.
[Unless someone invents an efficient way to make gas from sunlight, water and CO2. That'd be a good thing to invest in.]
I don't think you can really do what you describe. This sort of thing is all about problem solving, the detective work you do to find the cause (and then solution) when you are having some problem. If you know the answer to begin with, you can't go through the process.
If your ultimate goal is to learn more about networking, then I'd say you can learn a lot by running a network analyser (ethereal is a very good gui tool which understand a lot of protocols. It can also read tcpdump files, which is handy).
Look at the traffic on your network. Do you understand all of it (if not, go and read up)? Now reboot one of your boxes. Can you pick out the boot sequence traffic? Did any of it surprise you? Read some more.
Ideally, get a heterogenous network going. Stick a windows box on there. Repeat the above questions.
Set up some local file sharing protocols (e.g., samba, nfs, webdav) and shares. Watch the traffic. You'll see authorisation protocols in there now too.
Until something goes wrong, I'd say this is the best way to learn. There is a lot of detail in these protocols. And additionally, the best way to quickly fix a network when it is broken is to know what it looks like when it is running normally, which is something you have to do beforehand.
Last top tips:
- network problems are much easier to diagnose with 3 boxes. Given the problem "A and B can't talk X (or are very slow talking X)" there is a lot of trouble to shoot. Reducing that to "A and B can't talk X, but A and C can. Hmmm...and B and C can't" narrows the field quite a lot.
- always check the basics first. Things get more complex (and take longer to analyse) as you head up the network stack, so check the lowest layers first. Which are the lowest layers? Go and read a book on TCP/IP and always remember that the lowest layer is physical, so always check its plugged in...
Have you played guild wars? Its exactly what you want. The PvP is all tactics, with all PvPers being levelled to the same. There is some dependence on which skills and items you have "unlocked", but that isn't the main thrust of things. Success is about how your chosen character skills operate together and interact with those of your team. And of course how well you and your team mates do at using those char skills.
Also, no monthly fee (since most areas are instanced in a peer-to-peer way, with little server load, so ArenaNet's running costs are lower).
Sorry to sound like an advert, but it is a fun game and appears to fit what you are looking for. (Hmm...maybe *you* are the guild wars plant...asking that question to entice a positive response about the game. Damn, you're subtle).
Errm.
Different processes generally do run on different cores, on most multiprocess OSs I know of.
Child processes are related to the parent process (they have a parent-child relationship, the parent can pass some shared information into the child).
A greater degree of sharing (e.g. a shared memory space) is exactly what an (OS-level) thread is...a seperate, schedulable execution context which shares a memory space with its parent.
You're right in the pthreads API isn't the nicest one to work with. But in my experience that isn't the main problem with threading. The main problem with threading is that by default *everything* is shared. All the dirty little global, file scope and static variables in all the little libraries your app loads to get things done. And any write access to such shared data by multiple threads without appropriate locking is quite likely to be a hard-to-reproduce-and-find fault waiting to happen.
But your new API doesn't make much sense to me. Your additional parameter to 'exec' isn't about threading, in that you've specified an exe name. If you're creating another thread, you'd be in the same exe as the one executing the call - thats a redundant parameter.
The nearest thing to what you suggest would be a new parameter to fork() which shared the VM between the two processes. Funnily enough thats pretty much what fork() is implemented on top of in Linux. Underneath it all there is a 'clone()' system call which is used to create a new execution context. The flags to clone() determine how much is shared between the parent and child. If you share VM, you get something close to a new thread, if you don't, you get something close to a new process.
[The 'something close' is in there to guard against any pedants pointing out that if you are so inclined you can specify odd combinations of CLONE_ flags and get some weird entities which don't correspond to traditional threads or processes.]
See 'man clone' on a Linux box for details of a library level clone function built on top of the clone syscall.
But on the face of it, using clone() to create a thread isn't too different from a plain pthread_create(). And that doesn't get you too far, because you then need some locking mechanisms. All of a sudden you're adding API for mutexes, semaphores, condition variables and all that guff. And then you're back with something as unpleasant as the pthreads API. Well actually, you're not. Because that API does suck pretty hard.
Basically threading is something which probably benefits from language-level support. Java (and I assume C# and probably others) have some of this. But that doesn't help game developers who I assume will be writing their performance critical code in something a bit closer to the metal.
Without much effort on your part you could grab DrScheme (its packaged as part of some Linux distros, otherwise go to here. That's your graphical coding environment. It runs on Windows, Mac and Linux.
:-) more pragmatic language to learn to deploy applications in.
For material to accompany it, "How to Design Programs" is a good book available online in its entirety here.
If you're more hardcore, then you might prefer "The Structure and Interpretation of Computer Programs", another book online here. SICP also has about 20 hour-long downloadable lecture videos, but be prepared for 70/80s fashions in the audience...
I think HTDP is a great way to learn to program in general, and DrScheme is a good environment in which to learn.
Downsides: scheme isn't widely used outside of education. It is also not obviously closely related to mainstream languages (C++/Java/C#/Perl/Python/Ruby) in appearance.
Upsides: scheme is fairly easy to learn, so you can focus on picking up concepts and discovering if you enjoy programming. Scheme is a also a very close relative to lisp, which is a (slightly
Exactly. This seems so obvious to me too. You need:
- a display
- an input device (at least voice, probably written too assuming voice recognition doesn't do away with it)
- some processing power
- some storage
- networking (gsm, wifi, etc)
The only (technical) reasons to bundle more than one of these in the same package is to reduce overall form factor or to provide a wired pathway for bandwidth/security reasons.
We've got bluetooth headsets, we're able to plug usb stick/flash storage into things. What would it take to have a wirelessly-accessible hard drive in your backpack/jacket pocket?
And of course, the real payoff here is that you have your portable versions of all of these things, but you should be able to walk up to and use and "public" devices (e.g. large screen, full size keyboard) and have them automagically work with your programs, your data, your network, etc.
Kind of like the PC architecture have standard components and busses (ISA/PCI/etc). Manafacturers can manafacture to the interconnection spec, reducing the O(n^2) interoperability problem to O(n).
So...what would it take? A "bodybus" specification? PCI-over-wifi?
Ah, thanks for that. That seems to make more sense.
It does leave the question as to what people were thinking when they thought a post-fusion model the best explanation, but "thats not important right now".
Following this story, I was thinking about this gravitational collapse thing this morning.
It seems odd to me that falling matter can bounce back into a big explosion under gravitational power. Naively, you'd expect it to bounce back to the same "height". I guess some/most of the matter is staying at a lower potential energy, so that a small amount can be ejected with a large amount of energy?
Could you or anyone else give me a hint as to what I'm missing here? If it is the above scenario (most matter staying 'low'), could a similar effect be achieved on a smaller scale, in (a zero-g) lab (by allowing some fluid to collapse in on itself?).
One of the nice things about subversion (recently converted user, very happy so far) is the support for multiple url formats and communications methods.
Another notable thing (for windows users) is TortoiseSVN, (an explorer shell extension) which is just great.
I can see how the distributed, multi-repo model of bitkeeper/darcs/arch is superior but svn looks good if you only need single-repo.
Also, bitkeeper has some powerful gui tools (and probably the kitchen sink too). Haven't really used arch/darcs.
But be careful. If you know (because of knowledge of the problem domain) that N will be 50 for the next few years, there is no shame in a linear pass to find your entry.
Adding a code to maintain a sorted list and perform a binary search or adding hashing, all so you can scale nicely to N=1,000,000 kind of misses the point.
I think my point is that dumb algorithms are fine first implementations. Don't waste your time with a "better" algo if the problem doesn't demand it. (And how do you know the problem demands it? Well, really you should use profiling again, rather than "I may have lots of these").
EE Smith's "Lensman" series. Never has space opera been so much fun, or weapons systems built up to such ludicrous extremes. Good descriptions of large-scale engagements in space too (aha...I shall attack in theoretically-optimal cone formation! Hmmm....I shall shift my cone into a cylinder, with 10 layers of defense-only drone ships at the end and cut out the power-centre at the apex of your cone formation! Mwahahaha)
I really liked the way each generations "ultimate weapon" is trumped by the next...
Towards the end it is "no mobile craft can asault these fixed-placement weaponry" followed by "lets render entire planets inertialess and use those as ultimately powerful bases".
So how do you defend against unstoppable planets? Why...the sunbeam of course.
And that *must* be unbeatable, right? Wrong...
Damn, that series is fun.
Get a copy of K&R ANSI C (is there a C89/99 version now?). Read all the way through it and do those of the exercises which interest you.
C is a small language. The C standard library is small (and more importantly, it is *standard* and cross platform). It is both easy to learn and hard-core. It is also one way towards learning the "industry standard" C++ (some would argue that you shouldn't start from C, but as long as you don't develop too many bad habits I think its OK).
The biggest problem is that C allows lots of "bad habits". This can be mitigated by reading some coding style guidelines (I'd recommend the 'CodingStyle' document in the linux kernel source documentation, but others may recommend the GNU standards).
You can easily manipulate files and produce console (stdin/stdout/stderr) based code without calling any operating system specific APIs. (fopen/fclose etc are C standard, open(), close() are Unix/Posix).
I personally write two programs to learn a new language/environment: a hex dumper and an implemenetation of the "sieve of eratosthenes" for finding primes. Between the two of them you get to deal with various data types and conversions, file and screen I/O and you've got enough functionality to make it worth structuring a little (pulling out functions/methods), so you end up learning useful stuff.
If you want to get into GUI coding, you're going to have to pick a GUI toolkit. Those *are* daunting. Don't try and do the cross-platform thing to start with. Hitch yourself to GNOME or KDE and get going.
But if it were me[*], I'd do the above to get my basics straight and then try and find a project of interest. The nice thing about contributing to an existing project is that the hard work of infrastructure is aleady there (someone else has set up the makefiles, etc etc). The downside is that you need to learn how to fit your work in with someone else modus operandum. This last is more a social than technical issue, but hey, that is your current core competency right?
Good luck. Go and do it, keep a diary then post a "here is how I got on" story in a few months. That should give you something to aim for, too.
[*] it kind of is me, except I'm about two years younger and switched back to a dev post a couple of years back after several years as a sys/net-admin and consultant.
No, but the NNTON album (yes, "long playing vinyl, 33rpm) is on the shelf in another town, so I should go and grab it sometime
Comedy gold, pure comedy gold.
Do the yanks get any "Not the Nine o'clock News"? Is it too dated anyway?
"Wild? I was livid!"
Doesn't get any better than that...
The comment from Linus isn't about using estoppel as a sword.
LT notes that his comments in COPYING allow *someone else* to know that they have the shield of estoppel on this matter.
i.e. he is saying that he isn't modifying the GPL per se, but anyone with a lawyer would be able to read the comments in the COPYING file and have confidence that they could link+distribute their non-derived works (binary modules) with the kernel (since they could have a reasonable expectation of estoppel).
There are some good threads (no links, too lazy) on this in the LKML archives. In particular, Linus's views on what constitutes a derived work I found interesting.
re: lawyers copying copyrighted contracts, the fact that an act is commonplace doesn't make it legal. (It may be legal for other reasons, e.g. fair use, but I don't think your point stands). Witness speeding (in the UK) and sharing MP3s. Whether that makes it harder to get a prosecution, I wouldn't know.
Disagree. Saruman had lots of excuses for what he got up to. At least initially, he was doing the "we need power to fight power" argument.
Because you are copying from a disk to itself.
:-)
All the "max bandwidth" figures you see are for streaming reads, where the disk heads move (relatively) smoothly along logically continguous chunks of disk.
Compare that to copying from one part of the disk to another. Your 100Mbyte file will be copied in chunks. The sequence of events will go something like this at a low level:
while( data left to copy )
{
move disk heads to offset in file to be read
read a chunk
move disk heads to offset in file to be written
write a chunk
}
The bit that really costs you is the two seeks. For a disk with an advertised seek time of 10ms, you are paying 20ms per chunk on top of your read+write times.
20ms/chunk == 50 chunks/second. So, 5Mbytes/second would be 100Kbytes/chunk, (assuming the actual read+write are free). [If you meant 5Mbits a second that would be ~12Kbytes/chunk.]
If you had two disks (on different disk controllers, etc etc). The disk heads wouldn't need to seek around much at all, and you'd get much closer to the theoretical bandwidth.
Or if you have a RAMdisk (and enough RAM), you could try:
cp bob/file to RAMDISK/file
cp RAMDISK/file fred/file
which should also run at full speed.
Also - note that if you do any other task which involves reading or writing to the disk at the same time, you'll hurt performance even more.
Its not the case that "time taken to perform tasks A and B in parallel" == "time taken to perform task A + time taken to perform task B", you also pay the cost of switching between them, which is comparitively steep in the case of disk I/O.
Does that make sense? Or Have I Been Trolled?
I think we are in agreement. Your nationality (a political concept) is British.
:-)
But as an inhabitant of the geographical region of the island of Britain, I am a Briton/British person. This happens to be the same as my nationality, but it needn't be. I am also geographically an English person. Its a multiple-value thing. Ditto I am a European person (I guess both geographically and politically).
My point of interest is whether *geographically* inhabitants of Northern Ireland might consider themselves as Irish people. I thought they might, but also (quiet reasonably) the question is so charged with political overtones that some might not want to do so.
(Its quite similar to the way Canadians and inhabitants of the USA are both North Americans. A person born in Canada is Canadian by nationality, and is geographically also a Canadian, a North American and I guess a Western Hemi-spherian).
I'm beating this horse to death because there is huge overlap (and hence misunderstanding) regarding these two terminologies, and I'm interested in people communicating effectively (especially when they are disagreeing/discussing things). I'm also interested to get a larger sample of N. Irish people to answer this particular question
Your way of avoiding confusion seems very pragmatic...
Geography and politics here.
:-)
There is a geographical entity known as the British Isles, consisting of a large island called Britain, a slightly smaller island called Ireland and a number of significantly smaller islands (Isle of Man, Isle of Wight, etc).
Geographically, one might call an inhabitant of Britain a Briton (or British person) and an inhabitant of Ireland an Irish person (don't know of an equivalent noun).
The reason this is sensitive is that the political arrangements do not follow geographical lines and I'm not going to touch the topic of whether they should or not.
I suppose one might be able to call both of these inhabitants British (due to their living in the British Isles) but that seems overly antagonistic to those living in the country of Eire (a country which covers the majority of the geographical entity of Ireland) and certainly doesn't follow common usage.
Politically, I think people use "British" as a nationality to identify with "being a citizen of the UK" and "Irish" to identify "being a citizen of Eire".
I might imagine (but would not wish to presume) that an inhabitant of Northen Island (a region of the UK which lies in the island of Ireland) might describe themselves as both British (nationally) and Irish (geographically).
I think there is a lot of confusion on these issues, and I welcome corrections and clarify on this terminology.
As to being in Europe, I think it depends on the rotating European presidency. Whilst Berlusconi is EU president I think we're not
Sure. I was commenting on the tangent regarding the number of worldwide mail domains.
Howver, 100k is also a low estimate for hosts.
In 2001, Dan Bernstein did this survey which yields an internet-wide estimate of 4 million reachable IP addresses running an SMTP server. I doubt the figure has decreased.
Scalability over many orders of magnitude is a fairly key requirement for internet protocol design.
I think 100k mail domains worldwide is a little on the low side. One ISP to my knowledge hosts over 30k mail domains. Of course, that could just be our cool software :-)
> So... your security model breaks utterly as soon
> as someone finds a bug in the *compiler*?
The bugginess (or otherwise) isn't the main issue. You can think of the checks done in the compiler regarding access permissions as equivalent to the checks done by the system call interface at run time (and by the page fault handler, etc). If either is buggy (e.g. the recent mremap() bug in the Linux kernel) you get privilege escalation (of course, such checks are particularly difficult at compile time for some languages, e.g. anything with real pointers).
Basically the system comes down to transitive trust. The kernel could assume trust in one (or more) compilers, such that it is happy running the output of those compilers without run-time checks.
Note:
1 - You could have multiple trusted compilers, for whichever languages you favour.
2 - You don't need to enforce your trust relationships via digital signatures (although that would be one way). One alternative method would be to allow only "trusted" processes to mark another process as executable. Then, compilers would mark their output as executable.
3 - Other processes could run, but in a run-time sandbox (own address space, system call checking etc)
4 - Oops. Look at what we've got. Unix. "trusted" == root, except that system calls made by root owned processes would bypass all run-time checks.
OK, so that isn't a perfect view of things (it is useful to have run-time checking on most/many root processes), but you could certainly envisage a new capability which allowed a process to run in the kernel address space?
That doesn't seem as much of a far off idea now?