No, support for position independent code was limited. Relocation support has nothing to do with the CPU, and can be done just as easily on a 6502/6510 as any other CPU (you keep track of what offsets in the code need to be relocated, and store offsets instead of absolute addresses, then when you load you add the base address you've chosen to all the offsets that needs relocating, roughly speaking).
On a 6510 I'm pretty sure a relocating loader could be written in a few hundred bytes of assembly provided you ensure the object format is simple.
Of course memory protection would be nice, but remember most of the Amiga models didn't have memory protection either, and in fact a lot of Amiga users argued against adding it because of the overhead it adds.
The point is it might be worth buying SCO just for the IP, even if they just shut down the company, both to prevent any further ridiculous lawsuits and save themselves the trouble (and risk), as well as to risk any further problems with licensing other technology from SCO.
I've had the pleasure of seeing Slashdot'ings from the side of the server 3-4 times or so at my two last employers, and it's not that bad - if you're lucky maybe 20-30 gigs of extra traffic. If you're with a decent hosting provider that won't cost you more than 20-60 USD. Of course there are providers out there that charge you more than 5USD a gig too, but if you're using someone like that you get what you deserve:-)
It also ignores the number of companies with SMP and NUMA experience (SGI, anyone?), as well as individuals with significant experience in the area, that have contributed significantly to the Linux kernel. It's not as if good SMP and memory management solutions in Linux have all come from IBM.
It's interesting how powerful popular culture is when you see KBabel as a play on the babelfish and not on the tower of babel (which is arguable where the babelfish got it's name from). Even an atheist like me who's never read the bible made that connection;).
You sort of have clearly defined languagle-level constructs and rules about what happens when you use new. The only thing you know for sure is that you either get an exception or a pointer to a memory area that's supposed to be large enough to hold a QPushButton.
The language doesn't specify what kind of memory it is. It might be allocated directly in a file using mmap, it might be doing fancy stuff with memory maps to do all kinds of weird and wonderful things whenever you write to it (or not allow you to write to it at all), or a zillion other things only limited by the fantasies of some of the most imaginative people around:) Remember, you can provide your own new handler.
As for the state of the object, you have no idea without knowing what the QPushButton() constructor does. It could be left completely uninitialized because initialization is costly and it's left to the user to call an init() method, the user may be expected to set various properties, or everything might just have been zero'ed out.
In other words: You are relying on convention to say what operator new does, and on your assumptions about what a class with the name QPushButton() should do, or specific knowledge about this particular class to tell you what you expect the constructor to do.
Which is, suprise, surprise, the exact same starting point you have with a function called gtk_button_new_with_label(), except that in my opinion the latter name give you a better clue to what the argument is. In the first case it is not clear without going to documentation whether the argument to the constructor is the text on the button, keyboard accelerators, and internal id used in callbacks (why am I supposed to assume that QPushButton has a text label?), or something else entirely.
And your comment about having to write a x_button_new_with_specific_property function is also more about syntax than semantics - a constructor is a function too, the only difference between the two is that in the first case you have explicit control over how memory is allocated, whereas in the latter to you take what's coming. The first case allows a lot of flexibility to the class implementor that isn't available when using the operator new syntax in C++, hence patterns related to object construction often require the user to use a different syntax even when the user has no need to know.
As for the number of _new functions with permutations of _with_, you have the exact same problem with C++ constructors: You need to remember the syntax (the order and type of the arguments) of the constructors. With GTK's naming scheme on the other hand, you're a hell of a lot less likely to call the wrong constructor because you remember wrong, pushing more errors from runtime to compile time, which in my book is good.
If you need more than 2-3 constructors tops, you should be looking at way to more clearly syntactically differentiate them even if you use C++. Eiffel for instance allow differently named constructors for the same class, and that might have been useful for C++ too. Another alternative is of course to use static class member functions, but then we're back to the different syntax for object construction issue that I mentioned above.
I like C++, and personally don't do much GTK programming, but from your message it is not at all clear to me that you've demonstrated any superiority in C++ object oriented programming with your message (I'm not saying there aren't any, just that you'll have to try harder:-) except for "it looks prettier" and that you think C++ guarantee you more than it does.
No it wouldn't. NT solve this problem by giving a static boost in priority to processes that own windows in the foreground, and give the GUI higher priority. The latter can be done in Linux with nice, the former would be a trivial patch (or you could manually nice the X clients you want to give priority to), however neither are seen as good solutions as they require the user/distributor/sysadmin/developer to decide on which tasks deserve the boost, and the boost is given regardless of whether the process in question is actually important to anyone.
With the patch in question, the kernel automatically responds to a certain pattern of activity, regardless of whether it's X or some other process that is responsible for holding up interactive processes, and so the solution is far more generic.
A typical example would be with component architectures such as Bonobo or KParts. If some interactive task depends on a CPU hog of a component, this change would ideally give the component a boost too (I say "ideally" because the patch currently only look at Unix domain sockets, and I've got no idea whether either Bonobo or Kparts use Unix domain sockets for parts of their communication).
There's a patch for making the Linux scheduler preemptive within kernel space as well, however that wouldn't solve the problem that has now apparently been solved, which is that many tasks that are themselves considered non-interactive by the scheduler still dramatically affect interactive behaviour because a lot of interactive tasks depend on them.
X is the most important example, since it doesn't help how much CPU your xterms or other X clients you run get if X doesn't get enough CPU time to service them, as if X doesn't get enough time the only thing extra CPU time will give your x clients is the ability to go back to sleep faster and more often.
Realtime scheduling is something else alltogether. Realtime scheduling is about predictability, not about CPU time allocated. With a realtime scheduler you can guarantee that task A get some time at least every 10ms, for instance, but if you're maxing out the CPU you still need a way of deciding which tasks have priority, or reduce their overall time slices.
The kernel patches in question attempts to decide which tasks to give priority
automatically, instead of resorting to hacks like using nice on specific processes. It achieves that by making the assumption that if task A is interactive, and it frequently waits on B, then task B needs to get more CPU too.
Since a high load desktop scenario will likely have lots of clients waiting on X the result is that X will get more CPU even if X itself isn't an interactive task, and hence the machine will hopefully feel more responsive.
The way this is being accomplished is good because it doesn't special case - any non-interactive task that provides vital services to interactive tasks will get more CPU (though in this particular implementation, I believe only if they communicate using Unix domain sockets), without the user or developers having to guess which processes should get it.
Before you discount the strength of a rabbit, try cornering an adult rabbit and see how nice it is to get kicked by it...:-) They're perfectly capable of fighting off quite large animals by turning around and kicking their attacker with their back legs. While I still lived with my parents, we had both a cat and rabbits once, and for some reason the rabbit had been let loose for a while, but someone forgot to put it back in it's cage. The cat obviously thought that chasing a rabbit was a quite nice pasttime, but at some point it cornered the rabbit and got a quite nasty surprise. After that, whenever it saw the rabbit it looked away or pulled away, and stuck to cat food:)
Even humans can get quite bad marks getting kicked, scratched or bitten by rabbits if they aren't careful with their pets - rabbits are a lot less wimpy than they look.
As someone else has already pointed out, you are making assumptions about what would be evolutionary beneficial to us that simply doesn't hold.
For example, there is little evolutionary advantage for us in remaining physically strong after we've had children and brought them up. And in todays society, physical strength is less and less of an evolutionary advantage even earlier.
On the other hand, there has been a distinct evolutionary disadvantage in being stronger than "needed": Muscle mass burn more calories, which mean you'll need to eat more to sustain yourself. Now, for most people in industrialized countries today this is an advantage, not a problem, as an increasing number of us struggle to keep slim and fit, but someone with less muscle mass, more body fat and low metabolism would be much more likely to survive a famine.
Now this is an example of a case where evolution doesn't match todays society, where being overweight is a problem for many people, and doesn't provide the advantage, as most of us don't have to deal with famine. It's possible evolution will eventually catch up, but even then evolution will always reflect only what makes us most likely to procreate and create offspring that will survive, not on what give us a chance to live long, healthy, full lives.
My experience is the same, and even my girlfriend, who hadn't ever seen Linux before she moved in with me is now a devoted tab user. She'll often have 20+ tabs open spread over 3-4 Mozilla windows... Thats well above what I'd use...
Look at Nigeria as an example. The number of phone lines has stood still at about 400.000 for a country of 120 million people for a long time. The primary reason being that Nitel have large problems affording to build out the infrastructure further, in part because of extensive theft of phone cables as well as plain vandalism. MTN on the other hand aquired more than 400.000 cellphone subscribers in Nigeria in it's first 9 months of operation alone, growing by about 85.000 between March and April 2002 alone (I don't know how many subscribers they've added since then).
It's commonly estimated that Nigeria will have more than 18 million cellphone subscribers in 5 years time.
Why? Because building out a cellphone network is CHEAP compared to laying cable, particularly when you can expect the cables to be damaged or stolen on a regular basis.
Cellphone networks can easily be used for data transmissions - the GSM protocol allow channel bundling, so even high speed links are possible. So already today, wireless access to the internet would allow a far wider reach than landlines in Nigeria.
The reason internet cafes in the developed world use fixed line access is that the developed world is already wired. Enormous amounts of money have been sunk in laying copper wires everywhere, and the cost have already been written off, while technology keeps on increasing the amount of data we can shove down the wires. For countries with large distances and without an existing extensive
landline infrastructure it is simply not cost effective.
So in this case it is landline based networks that are "fancy", and wireless networks using repeaters that is the cheap, cost effective alternative.
I agree with you about internet cafe's as a good place to meet and provide access. It's important to focus in this, as the point is to provide access to people who are unlikely to afford a computer (or for that matter their own radio, telephone or TV).
However long range wireless solutions might be very suitable for many of these countries for bringing internet access to the cafes, because the poverty levels means that even phone lines get stolen quite often for the copper many places (some countries have even had cases of people cutting down power cables to sell the scrap metal).
Securing a number of wireless routers might be easier than securing miles and miles of cable. Additionally, putting up phone cables is expensive, and many African countries have extremely under developed landline networks, and it's not a given that setting up wireless connections won't be cheaper.
Bell's "national IP infrastructure" is as close to the internet as the phone network is - it is a private IP network where they can enforce as much
redundancy and quality of service as they like, which means guaranteeing
bandwidth and latency is not a problem. Unless their system is badly flawed,
packet loss, DDoS or intermittent hardware failures should not be a problem.
What do you mean a minimum one second lag? With a decent connection (read: not dialup or ADSL etc.) and decent equipment getting down to a couple of hundred milliseconds round trips for transatlantic connections isn't a problem.
But still, using the internet as opposed to hiring a dedicated channel for an application like this would be stupid.
Noone sane would use the public internet for an application like this - you would use a guaranteed quality of service link set up for the purpose, and that can easily be provided nearly anywhere. Your phone calls are typically allocated a fixed bandwidth digital channel from your local exchange onwards, for instance. If you're worried about redundancy, setting up a VPN with a redundant connection through a physically separate line should be no problem for any telco. Yes, you would pay lots more than for your home internet connection, but then it would still be peanuts compared to the cost of a long operation anyway.
They've agreed to the full text. In most European countries you are not finally aquitted of anything until the appeals process have been exhausted or neither side files an appeal within a certain short timeframe. You can argue all you want, but it's hardly an accident that the paragraph is worded as it is - under your interpretation it would require major restructuring of the legal systems in a large number of the signatory countries, which simply isn't likely.
The "main trust" of the law is that a defendant should only be subjected to a limited prosecution, and once finally aquitted in a case should not face further trials, allowing the government to use continuous harrassment as a way of punishing without a judgement. Whether that is handled by one, two or three courts (or more for that matter) is vitally different from allowing prosecution to go on and on without limit. It's the latter that the paragraph in question is meant to protect against.
Interestingly, the current British government is considering reducing the double jeopardy protection from US levels to something more in line with what's common elsewhere in Europe. Further, the EU is working on "Corpus Juris" a common criminal code for the entire EU, that in it's current draft incarnation specifically allow the prosecution to appeal an aquittal, in line with most national European criminal codes.
Double jeopardy in the UK and US form is in fact quite rare outside countries that derive their legal system from English common law.
Read the article, will you. Transmeta has licensed AMD's x86-64 technology, and thus have everything to gain from low market acceptance for the Itanium.
And provided that your app will work cleanly on a 64bit architecture, which is certainly not a given (int vs pointer size assumption and alignment issues being common problems).
As long as memory keeps getting cheaper and people are prepared to keep upgrading software companies have no incentives to spend resources on reducing bloat. Developer time is costly, and often it makes far more economic sense for the software companies to shove something out the door as soon as it works (or even before;) without spending more time cutting memory usage when most users will have enough memory soon enough anyway.
Argh. That's what I get from writing when I'm sleepy. The above should read "Yes, as I've proven by giving another view, there is another way to look at it:"
Yes, as I've proven by giving another view, it another way to look at it: Japan was weak. It's military was near collapse, and stretched way to thing, and a military victory without the bomb, even the first one, would have been possible relatively quickly, and with far fewer casualties.
Stupidity on the part of a dramatically weakened enemy you'd be able to defeat quickly anyway doesn't justify mass murder of civilians.
The direct responsibility of the destruction caused by a weapon lie with whoever uses it, no matter how much indirect responsibility other involved parties may have.
Slashdot Mirror
On a 6510 I'm pretty sure a relocating loader could be written in a few hundred bytes of assembly provided you ensure the object format is simple.
Of course memory protection would be nice, but remember most of the Amiga models didn't have memory protection either, and in fact a lot of Amiga users argued against adding it because of the overhead it adds.
The point is it might be worth buying SCO just for the IP, even if they just shut down the company, both to prevent any further ridiculous lawsuits and save themselves the trouble (and risk), as well as to risk any further problems with licensing other technology from SCO.
I've had the pleasure of seeing Slashdot'ings from the side of the server 3-4 times or so at my two last employers, and it's not that bad - if you're lucky maybe 20-30 gigs of extra traffic. If you're with a decent hosting provider that won't cost you more than 20-60 USD. Of course there are providers out there that charge you more than 5USD a gig too, but if you're using someone like that you get what you deserve :-)
It also ignores the number of companies with SMP and NUMA experience (SGI, anyone?), as well as individuals with significant experience in the area, that have contributed significantly to the Linux kernel. It's not as if good SMP and memory management solutions in Linux have all come from IBM.
It's interesting how powerful popular culture is when you see KBabel as a play on the babelfish and not on the tower of babel (which is arguable where the babelfish got it's name from). Even an atheist like me who's never read the bible made that connection ;).
The language doesn't specify what kind of memory it is. It might be allocated directly in a file using mmap, it might be doing fancy stuff with memory maps to do all kinds of weird and wonderful things whenever you write to it (or not allow you to write to it at all), or a zillion other things only limited by the fantasies of some of the most imaginative people around :) Remember, you can provide your own new handler.
As for the state of the object, you have no idea without knowing what the QPushButton() constructor does. It could be left completely uninitialized because initialization is costly and it's left to the user to call an init() method, the user may be expected to set various properties, or everything might just have been zero'ed out.
In other words: You are relying on convention to say what operator new does, and on your assumptions about what a class with the name QPushButton() should do, or specific knowledge about this particular class to tell you what you expect the constructor to do.
Which is, suprise, surprise, the exact same starting point you have with a function called gtk_button_new_with_label(), except that in my opinion the latter name give you a better clue to what the argument is. In the first case it is not clear without going to documentation whether the argument to the constructor is the text on the button, keyboard accelerators, and internal id used in callbacks (why am I supposed to assume that QPushButton has a text label?), or something else entirely.
And your comment about having to write a x_button_new_with_specific_property function is also more about syntax than semantics - a constructor is a function too, the only difference between the two is that in the first case you have explicit control over how memory is allocated, whereas in the latter to you take what's coming. The first case allows a lot of flexibility to the class implementor that isn't available when using the operator new syntax in C++, hence patterns related to object construction often require the user to use a different syntax even when the user has no need to know.
As for the number of _new functions with permutations of _with_, you have the exact same problem with C++ constructors: You need to remember the syntax (the order and type of the arguments) of the constructors. With GTK's naming scheme on the other hand, you're a hell of a lot less likely to call the wrong constructor because you remember wrong, pushing more errors from runtime to compile time, which in my book is good.
If you need more than 2-3 constructors tops, you should be looking at way to more clearly syntactically differentiate them even if you use C++. Eiffel for instance allow differently named constructors for the same class, and that might have been useful for C++ too. Another alternative is of course to use static class member functions, but then we're back to the different syntax for object construction issue that I mentioned above.
I like C++, and personally don't do much GTK programming, but from your message it is not at all clear to me that you've demonstrated any superiority in C++ object oriented programming with your message (I'm not saying there aren't any, just that you'll have to try harder :-) except for "it looks prettier" and that you think C++ guarantee you more than it does.
With the patch in question, the kernel automatically responds to a certain pattern of activity, regardless of whether it's X or some other process that is responsible for holding up interactive processes, and so the solution is far more generic.
A typical example would be with component architectures such as Bonobo or KParts. If some interactive task depends on a CPU hog of a component, this change would ideally give the component a boost too (I say "ideally" because the patch currently only look at Unix domain sockets, and I've got no idea whether either Bonobo or Kparts use Unix domain sockets for parts of their communication).
X is the most important example, since it doesn't help how much CPU your xterms or other X clients you run get if X doesn't get enough CPU time to service them, as if X doesn't get enough time the only thing extra CPU time will give your x clients is the ability to go back to sleep faster and more often.
Realtime scheduling is something else alltogether. Realtime scheduling is about predictability, not about CPU time allocated. With a realtime scheduler you can guarantee that task A get some time at least every 10ms, for instance, but if you're maxing out the CPU you still need a way of deciding which tasks have priority, or reduce their overall time slices.
The kernel patches in question attempts to decide which tasks to give priority automatically, instead of resorting to hacks like using nice on specific processes. It achieves that by making the assumption that if task A is interactive, and it frequently waits on B, then task B needs to get more CPU too.
Since a high load desktop scenario will likely have lots of clients waiting on X the result is that X will get more CPU even if X itself isn't an interactive task, and hence the machine will hopefully feel more responsive.
The way this is being accomplished is good because it doesn't special case - any non-interactive task that provides vital services to interactive tasks will get more CPU (though in this particular implementation, I believe only if they communicate using Unix domain sockets), without the user or developers having to guess which processes should get it.
Even humans can get quite bad marks getting kicked, scratched or bitten by rabbits if they aren't careful with their pets - rabbits are a lot less wimpy than they look.
For example, there is little evolutionary advantage for us in remaining physically strong after we've had children and brought them up. And in todays society, physical strength is less and less of an evolutionary advantage even earlier.
On the other hand, there has been a distinct evolutionary disadvantage in being stronger than "needed": Muscle mass burn more calories, which mean you'll need to eat more to sustain yourself. Now, for most people in industrialized countries today this is an advantage, not a problem, as an increasing number of us struggle to keep slim and fit, but someone with less muscle mass, more body fat and low metabolism would be much more likely to survive a famine.
Now this is an example of a case where evolution doesn't match todays society, where being overweight is a problem for many people, and doesn't provide the advantage, as most of us don't have to deal with famine. It's possible evolution will eventually catch up, but even then evolution will always reflect only what makes us most likely to procreate and create offspring that will survive, not on what give us a chance to live long, healthy, full lives.
My experience is the same, and even my girlfriend, who hadn't ever seen Linux before she moved in with me is now a devoted tab user. She'll often have 20+ tabs open spread over 3-4 Mozilla windows... Thats well above what I'd use...
It's commonly estimated that Nigeria will have more than 18 million cellphone subscribers in 5 years time.
Why? Because building out a cellphone network is CHEAP compared to laying cable, particularly when you can expect the cables to be damaged or stolen on a regular basis.
Cellphone networks can easily be used for data transmissions - the GSM protocol allow channel bundling, so even high speed links are possible. So already today, wireless access to the internet would allow a far wider reach than landlines in Nigeria.
The reason internet cafes in the developed world use fixed line access is that the developed world is already wired. Enormous amounts of money have been sunk in laying copper wires everywhere, and the cost have already been written off, while technology keeps on increasing the amount of data we can shove down the wires. For countries with large distances and without an existing extensive landline infrastructure it is simply not cost effective.
So in this case it is landline based networks that are "fancy", and wireless networks using repeaters that is the cheap, cost effective alternative.
However long range wireless solutions might be very suitable for many of these countries for bringing internet access to the cafes, because the poverty levels means that even phone lines get stolen quite often for the copper many places (some countries have even had cases of people cutting down power cables to sell the scrap metal).
Securing a number of wireless routers might be easier than securing miles and miles of cable. Additionally, putting up phone cables is expensive, and many African countries have extremely under developed landline networks, and it's not a given that setting up wireless connections won't be cheaper.
This is hardly the public internet.
But still, using the internet as opposed to hiring a dedicated channel for an application like this would be stupid.
Noone sane would use the public internet for an application like this - you would use a guaranteed quality of service link set up for the purpose, and that can easily be provided nearly anywhere. Your phone calls are typically allocated a fixed bandwidth digital channel from your local exchange onwards, for instance. If you're worried about redundancy, setting up a VPN with a redundant connection through a physically separate line should be no problem for any telco. Yes, you would pay lots more than for your home internet connection, but then it would still be peanuts compared to the cost of a long operation anyway.
The "main trust" of the law is that a defendant should only be subjected to a limited prosecution, and once finally aquitted in a case should not face further trials, allowing the government to use continuous harrassment as a way of punishing without a judgement. Whether that is handled by one, two or three courts (or more for that matter) is vitally different from allowing prosecution to go on and on without limit. It's the latter that the paragraph in question is meant to protect against.
Interestingly, the current British government is considering reducing the double jeopardy protection from US levels to something more in line with what's common elsewhere in Europe. Further, the EU is working on "Corpus Juris" a common criminal code for the entire EU, that in it's current draft incarnation specifically allow the prosecution to appeal an aquittal, in line with most national European criminal codes.
Double jeopardy in the UK and US form is in fact quite rare outside countries that derive their legal system from English common law.
Intel was founded 1968 and AMD in 1970, so what was your point about AMD being "so young"?
Read the article, will you. Transmeta has licensed AMD's x86-64 technology, and thus have everything to gain from low market acceptance for the Itanium.
And provided that your app will work cleanly on a 64bit architecture, which is certainly not a given (int vs pointer size assumption and alignment issues being common problems).
As long as memory keeps getting cheaper and people are prepared to keep upgrading software companies have no incentives to spend resources on reducing bloat. Developer time is costly, and often it makes far more economic sense for the software companies to shove something out the door as soon as it works (or even before ;) without spending more time cutting memory usage when most users will have enough memory soon enough anyway.
That was my reaction too.
Argh. That's what I get from writing when I'm sleepy. The above should read "Yes, as I've proven by giving another view, there is another way to look at it:"
Yes, as I've proven by giving another view, it another way to look at it: Japan was weak. It's military was near collapse, and stretched way to thing, and a military victory without the bomb, even the first one, would have been possible relatively quickly, and with far fewer casualties.
The direct responsibility of the destruction caused by a weapon lie with whoever uses it, no matter how much indirect responsibility other involved parties may have.
Nothing forced anyone to use the second bomb.