If the device can leave the building it shouldn't have sensitive information on it, and it shouldn't have access to sensitive information, at least not without a separate form of authentication.
Sometimes sensitive information has to leave the building. An example is if you're going off to give a demonstration of a prospective product to a potential partner, whose buy-in is necessary to making the product viable at all; that'll be very commercially sensitive (well, depending on what you're doing) and it's not practical to demand that the partner always come to your site. (Assume there's an NDA in place, of course.)
Encrypted devices help a lot with such issues, though they're not magic bullets (particularly if there's no proper backup plan). Ownership is less important; it's often taken as a proxy for "set up right" (and if only that always corresponded in practice with things truly being configured correctly).
When did we start letting middle managers be the most stupid people in the organization?
We never did. Some of the people at the bottom are really quite thoroughly stupid, in a can-hardly-spell-or-do-math sense.
But the real problem is that the qualities to do well in one post are not necessarily those needed to well in the manager of that post. They're different jobs after all. Now, when someone is promoted into a new role, it's rather random as to whether they'll have the skills to do well at that role. Sometimes they do, and then they can thrive (well, potentially), and sometimes they don't. It's the second case that we're discussing here, and that's a self-selecting set; people don't bitch about good managers.
Instead of dumping the incompetent ones we seem to let them rise to the level of their incompetence.
Some people are very good at telling stories to their superiors that the superiors want to hear. That makes it very hard for the superiors to detect the problems brewing up, given that they can't watch every little thing themselves (there's just not enough hours in the day). Plus those superiors might be doing the same themselves...
In any case, the thing to watch for is where you've got an organization that tries to stop communication upwards from bypassing any layer of management. That's a true sign of a place that is ripe for management coverups of their incompetence.
Yes, there is! Magic pixie power! Instead of all those nasty electricity plants, we'll just have lots of magical pixies turning handles inside all of our motors to make them move! (Don't worry about electric light too; magic pixies shine by themselves!) And the best thing about magic pixies? They're magic, and don't need feeding!
sqlite do not work really well for concurent access, due to locking.
I know someone who wrote a database server by wrapping a server (written in a scripting language) around SQLite. He used it to replace Oracle at his customers. He said to me that it supported concurrent accesses through the same techniques that many of the big DB engines use (such as multiple levels of locking and rollback logs) but I couldn't confirm that independently.
In my direct experience, SQLite is fine with the multiple reader single writer scenario (provided you don't do something dumb like putting the DB on NFS). That covers a lot of use cases.
I've played around with Sqlite in the past. I'm not sure I'd want it as a drop-in replacement for either MySQL or PostgreSQL. I must admit, as a Java developer I'm more likely to use Apache Derby, which can be used embedded or client/server.
I use both SQLite and Derby in projects of mine (not in the same project!) and it is my experience that SQLite is a lot higher quality than Derby. It copes far better with abuse such as killing the process or attempting to access the DB from multiple processes, and it has far higher limits on column sizes. On the other hand, Derby is pure Java so it's easier to embed in a redistributable package, whereas SQLite uses a native JDBC "driver" (actually the DB engine itself).
The other one to consider is HSQLDB, but I've no practical experience with it.
Given the ubiquity of cell phones in this country, and TFAs assertion that roughly 25% of people are on prepaid.... I'd put a conservative guess around 40-50 million people in the US who just lost a good chuck of their 4th Amendment Rights with this ruling.
Technically, that's only true when they're in the area covered by the 6th Circuit. The argument made only potentially has persuasive power in the rest of the US, not binding power. The real question is whether some clever legal researcher can find a decision by another Circuit that is directly in conflict; if they can, that pretty much forces the Supremes to hear the case.
"Prisoners of war" is totally different from "losing diplomatic immunity". Ecuador countering in kind by closing the British embassy? It'd be tolerated, and pretty much expected. Making *captives* out of the diplomats? Ecuador would find itself with some new craters if they tried that, and the British public would support it. The British aren't exactly flower children when it comes to the use of their military, in case you didn't notice, even when their citizens *aren't* at risk.
I really doubt it would come to that. To do that sort of thing would cost a lot of money as it would require locating quite a chunk of military force close to Ecuador to be able to do the raid; Britain doesn't have any military bases anywhere close by or anything like the reach of bombers that the US has (on the grounds that the UK doesn't need to be a global policeman). Western South America is a part of the world where the UK simply doesn't even try to project much force.
Short of asking the Americans to do it for us (utter political poison if it was ever to come out!) we'd do nothing other than grump about it.
Look at the added java.io.PrintStream.printf() method that uses a variable argument list. Someone had to be a special kind of asshole to adulterate a strongly-typed OO-language with that bullshit when the obvious OO solution is an array for a second argument. That's the kind of modification made when someone is making a political point, not a design improvement.
I can't tell, are you arguing that's a good idea or bad idea? (That Java method takes an array of objects as its second argument; it just effectively annotates the source to say that the compiler should also convert all the arguments after the first into an array, with appropriate value boxing. That gives the effect of varargs while remaining safe, and you can pass an array in that you built yourself if you really want to. But whether you knew that or would have thought that it was good if you did know, I genuinely can't tell.)
"Any computer I use to check gmail is fully under my control."
That's not really webmail then, is it? Most products are more secure when you don't use them.
You're claiming it's only webmail if you access it from a dodgy webcafe in Vietnam? That's... a strange position to take.
OK, I've done a slight exaggeration of your position there, but really there's nothing about webmail that says you have to authenticate to it with a non-crypto identity (though particular services might not be so cautious) and from a device that you don't control utterly. Client devices are pretty cheap now, and common too, so you won't look strange for carrying yours around with you. You can even throw those who question it off by claiming that you're doing it because you only feel comfortable using a device with the right background wallpaper; they'll think you're a strange OCD type, but won't probe more deeply. Meanwhile, you get the benefit of knowing that you've not got physical keyloggers installed (and you know you've not installed malware on it, yes?)
I agree that big data is often crazy big. I wonder how some of this data is even moved around. 60 gigabits sounds amazing. But if the system is set up with map reduce or other cool tap into the data often something can be simply crafted that will produce stunningly useful data.
It all depends. The data is often very large at the point of collection and between there and the first point of analysis; it's only after that point that you can start to get the quantities down to a saner level. Even then it remains hard to ensure that you can actually search the data; you don't want the data to just sit there, you want to be able to do something useful with it. Yes, you can try putting some sort of tap on it as it is flowing past, but then you're always wondering whether you're monitoring the right thing; you might be ignoring something critical and you'd never know.
The Big Data trend is about capturing all of the data (or a much larger fraction than before) and looking through what you've got afterwards. Some of this is done with the like of Hadoop, some with commercial software. There are both SQL and NoSQL DBs in the mix. And more than a few python scripts I'd be willing to bet. (This is all independent of where the data is actually stored; that depends on the particular application, but you don't get into this sort of thing without thinking carefully about what you're doing. The physical constraints on moving that much data around mean you can't blunder in without a clue.)
If anything's going to kill Facebook, it will be decisions made by people who were only hired to make money. People who have no interest in what it's for, never will have interest, and are only there to monetize.
Yes and no; if the company doesn't make money then it is still in trouble. The hard part is that you've got to have both passion to deliver a good product/service and monetization of that so that you can afford to keep doing it, and a lot of companies find that very difficult.
It's feeling like one of those stocks that will eventually hit a $1 or less.
What's with the US fixation with whether the unit price of some particular stock is less than $1, when it's something you wouldn't normally hold just one of? Surely the price of a single unit doesn't matter too much; what matters is how much that value is when you multiply it by the total number of stocks (either in your holding or in the overall company, depending on what you're talking about).
Or is there some regulation that I don't know about (not being a US citizen or based in the US)?
They are suing because they believe that Google, Samsung, etc truly stole their ideas to make phones.
The problem is that the real innovation was that you can make a profit selling smartphones with a touch screen, and that's really difficult to patent. Particular details can be patented, but they can also be worked around. (The patent system deliberately encourages this.)
Apple may not be winning in market share, but they're KILLING IT in profits
Profits say how you did, not how you're going to do in 6 months time. Very large profits for a producer indicate that there's a market opportunity for other producers to come in and sell cheaper alternatives; those other producers will make less profit, but can greatly reduce the total amount of profit that the former market leader was making.
And if this isn't covered by standard market theory that's been around for many decades, I'll be very surprised!
Yeah... and BMW is about to go out of business if they don't expand from their single-digit market share. I think they'll be able to sustain a niche market with their margins, they always have.
Yes and no. Apple should be able keep going as a profitable niche player (which is what BMW is in the automobile market). The problem is that the network effects of the ecosystem of providers and having a high-end product that lots of people really wanted to buy will dissipate; the super-profitability that came with that will not last.
Call it the free market improving the efficiency for customers...
Second is that while Android sells more handsets, there is a clear profit disparity between the two. They aim at different markets to some degree, but Apple is share of profits is more than merely disproportionate. This could mean Android phones can't sell at the same prices, that there are just tons more Android phones eating what used to be the feature phone market (my guess by far), or just that handset makers are cramming as much hardware as they can afford to differentiate themselves.
My guess is that a much larger fraction of the profits are going to the carriers, which encourages them to push the Android devices to their customers. The customers don't really care one way or the other, but the carriers do. After all, why plug a device that earns you a few bucks a year net when you can get them to buy something that does roughly the same (and at a similar price) but where you get ten or a hundred times more profit? What's more, such a model encourages every carrier to push high-end smartphones, so the number of users will be much higher, and the number of apps will be much higher as they'll follow the users, and the media providers will also follow the users. Apple's profitability might be great, but the wheels are in danger of coming off their ecosystem. It's not helped by the relatively short lifespan of these mobile devices; users are not locked in for half a decade and nor are devs or content providers.
Try doing 1080p real time video over SSH, and manipulate it and you'll notice some lag.
So you're going to claim that GUIs cannot possibly work over networks because you can't stream 3Gbps over the open internet in a sustained fashion without hitting some problems with bandwidth and latency? Hmm...
Have you any actual experience with a networked server?
Yes. That's the day job.
The real problem is that you go from a situation where all components can talk to each other quickly to a situation where everything you do must be carefully analysed because each time you cross the boundary between local and remote you take a possibly big hit from latency and possibly also bandwidth if it's a lot of data.
Yes, but you've also got to handle the fact that you're in potentially-different security domains. That's where things get much trickier because you can't necessarily put the code where it makes things fastest. (Sandboxing technologies have come a long way, but it's still a real worry.) It's also the case that any solution for the remote case probably ought to be applied to the local case too.
I have a Master's degree in distributed systems, and the mere term "network-transparent" is probably a fallacy. In face of the huge performance implications of a network, the local-remote split most likely has to be explicit in some way, just like it is with web. Unless you don't crappy performance.
You the verb there. Just sayin'...
"Network-transparent" is a lie. You can't conceal their presence. (See NFS and SMB/CIFS for examples of leakiness of abstractions.)
Is it just me or do some of those screenshots show significant rendering bugs like a failure to erase text correctly? (That's in the VTE demo.) Aside from that, are there any impressive demos?
Similarly X has 30 year history of really really doing a bad job of delivering a smooth GUI experience. That while in theory the network protocol shouldn't cost much, in practice it often seems to complicate design tremendously. X supporters IMHO and experience have trouble often admitting how many GUI projects fail or take 10x longer than they should because of the complexity of working with the X / multiple window manager / multi GUI stack.
That's an interesting assertion you're making there, that supporting a networked protocol causes excessive complication in the server. Would you care to provide (or point to) some evidence for that?
In my experience, the hard parts of making GUI code are dealing with multiple platforms (why would you want to write code for a single platform?) and going from functional-but-dull to snazzy-and-usable. The networking side of things (or not) is nowhere on that map.
you already generally have to use something like VNC or xpra (layered over X, not really using it) in order to get reasonable performance or to detach and reattach remotely.
X might seem like the answer until you try to use it... it isn't good enough because it's nowhere near usable as GNU screen.
Quite apart from the fact that terminals are a heck of a lot simpler than a GUI system, there are plenty of cases where high performance and detaching simply aren't needed. So what if the program goes away when you close the connection? You can run it again when you connect again, no problem. That's worked fine for all the cases in the past 5 years where I've needed remote X (such as installing engineering simulators or running certain types of performance monitors).
But the fact that you're comparing X11 to screen merely indicates that you're an insightless noob. Me? There's a lot about X11 that I don't like and there are some design decisions that are starting to look like really bad limitations, but that's because I've actually written toolkit code that uses X11; I know where many of the bodies are buried. Yet instead of kicking at the open door, you're trying to attack X11's strengths.
Numerical Methods will teach you exactly when and why rounding errors to happen, how they can compound each other, and in general help you write squeeky-clean math code.
Numerical methods is the course that all programmers should take and hardly any do (or at least not and think about what they've learned afterwards).
The one discipline that you don't mention that you perhaps should have done is logic. Programmers tend to be very good at logic, as programs are always logical constructions. A working programmer will deal with logic (especially boolean logic) day in, day out for years, so knowing what's going on with it will help a lot. I suppose programmers mostly think it's obvious and so forget to mention it...
Serious logicians say that math is a branch of logic (just like physics is a branch of math, chemistry a branch of physics, etc.) Serious philosophers say that logic is a branch of their discipline. Myself, I recommend math in school because it helps you think in an organized way, and that's ever so useful whatever you're doing with your life.
Well, unless your life plan is to sit around at home in your underpants eating cold instant ramen while watching Star Trek marathons.
The one difference is that truth is considered a defense in the U.S. while in the U.K. it can still be considered irrelevant.
The main difference there is that something being true doesn't mean that you have a right to say it; certain parts of the truth are still unreasonable and harmful to say. Something being the truth does shift the onus much more strongly towards the plaintiff to show that it shouldn't have been said though. It doesn't come up very often, to be honest.
Slashdot Mirror
Drive at 30-50% over the speed limit, and it's not boring any more.
All that time evading the pursuing cops is bound to make it more interesting!
If the device can leave the building it shouldn't have sensitive information on it, and it shouldn't have access to sensitive information, at least not without a separate form of authentication.
Sometimes sensitive information has to leave the building. An example is if you're going off to give a demonstration of a prospective product to a potential partner, whose buy-in is necessary to making the product viable at all; that'll be very commercially sensitive (well, depending on what you're doing) and it's not practical to demand that the partner always come to your site. (Assume there's an NDA in place, of course.)
Encrypted devices help a lot with such issues, though they're not magic bullets (particularly if there's no proper backup plan). Ownership is less important; it's often taken as a proxy for "set up right" (and if only that always corresponded in practice with things truly being configured correctly).
When did we start letting middle managers be the most stupid people in the organization?
We never did. Some of the people at the bottom are really quite thoroughly stupid, in a can-hardly-spell-or-do-math sense.
But the real problem is that the qualities to do well in one post are not necessarily those needed to well in the manager of that post. They're different jobs after all. Now, when someone is promoted into a new role, it's rather random as to whether they'll have the skills to do well at that role. Sometimes they do, and then they can thrive (well, potentially), and sometimes they don't. It's the second case that we're discussing here, and that's a self-selecting set; people don't bitch about good managers.
Instead of dumping the incompetent ones we seem to let them rise to the level of their incompetence.
Some people are very good at telling stories to their superiors that the superiors want to hear. That makes it very hard for the superiors to detect the problems brewing up, given that they can't watch every little thing themselves (there's just not enough hours in the day). Plus those superiors might be doing the same themselves...
In any case, the thing to watch for is where you've got an organization that tries to stop communication upwards from bypassing any layer of management. That's a true sign of a place that is ripe for management coverups of their incompetence.
There is no single solution
Yes, there is! Magic pixie power! Instead of all those nasty electricity plants, we'll just have lots of magical pixies turning handles inside all of our motors to make them move! (Don't worry about electric light too; magic pixies shine by themselves!) And the best thing about magic pixies? They're magic, and don't need feeding!
(Sheesh!)
sqlite do not work really well for concurent access, due to locking.
I know someone who wrote a database server by wrapping a server (written in a scripting language) around SQLite. He used it to replace Oracle at his customers. He said to me that it supported concurrent accesses through the same techniques that many of the big DB engines use (such as multiple levels of locking and rollback logs) but I couldn't confirm that independently.
In my direct experience, SQLite is fine with the multiple reader single writer scenario (provided you don't do something dumb like putting the DB on NFS). That covers a lot of use cases.
I've played around with Sqlite in the past. I'm not sure I'd want it as a drop-in replacement for either MySQL or PostgreSQL. I must admit, as a Java developer I'm more likely to use Apache Derby, which can be used embedded or client/server.
I use both SQLite and Derby in projects of mine (not in the same project!) and it is my experience that SQLite is a lot higher quality than Derby. It copes far better with abuse such as killing the process or attempting to access the DB from multiple processes, and it has far higher limits on column sizes. On the other hand, Derby is pure Java so it's easier to embed in a redistributable package, whereas SQLite uses a native JDBC "driver" (actually the DB engine itself).
The other one to consider is HSQLDB, but I've no practical experience with it.
Given the ubiquity of cell phones in this country, and TFAs assertion that roughly 25% of people are on prepaid.... I'd put a conservative guess around 40-50 million people in the US who just lost a good chuck of their 4th Amendment Rights with this ruling.
Technically, that's only true when they're in the area covered by the 6th Circuit. The argument made only potentially has persuasive power in the rest of the US, not binding power. The real question is whether some clever legal researcher can find a decision by another Circuit that is directly in conflict; if they can, that pretty much forces the Supremes to hear the case.
"Prisoners of war" is totally different from "losing diplomatic immunity". Ecuador countering in kind by closing the British embassy? It'd be tolerated, and pretty much expected. Making *captives* out of the diplomats? Ecuador would find itself with some new craters if they tried that, and the British public would support it. The British aren't exactly flower children when it comes to the use of their military, in case you didn't notice, even when their citizens *aren't* at risk.
I really doubt it would come to that. To do that sort of thing would cost a lot of money as it would require locating quite a chunk of military force close to Ecuador to be able to do the raid; Britain doesn't have any military bases anywhere close by or anything like the reach of bombers that the US has (on the grounds that the UK doesn't need to be a global policeman). Western South America is a part of the world where the UK simply doesn't even try to project much force.
Short of asking the Americans to do it for us (utter political poison if it was ever to come out!) we'd do nothing other than grump about it.
Look at the added java.io.PrintStream.printf() method that uses a variable argument list. Someone had to be a special kind of asshole to adulterate a strongly-typed OO-language with that bullshit when the obvious OO solution is an array for a second argument. That's the kind of modification made when someone is making a political point, not a design improvement.
I can't tell, are you arguing that's a good idea or bad idea? (That Java method takes an array of objects as its second argument; it just effectively annotates the source to say that the compiler should also convert all the arguments after the first into an array, with appropriate value boxing. That gives the effect of varargs while remaining safe, and you can pass an array in that you built yourself if you really want to. But whether you knew that or would have thought that it was good if you did know, I genuinely can't tell.)
"Any computer I use to check gmail is fully under my control."
That's not really webmail then, is it? Most products are more secure when you don't use them.
You're claiming it's only webmail if you access it from a dodgy webcafe in Vietnam? That's... a strange position to take.
OK, I've done a slight exaggeration of your position there, but really there's nothing about webmail that says you have to authenticate to it with a non-crypto identity (though particular services might not be so cautious) and from a device that you don't control utterly. Client devices are pretty cheap now, and common too, so you won't look strange for carrying yours around with you. You can even throw those who question it off by claiming that you're doing it because you only feel comfortable using a device with the right background wallpaper; they'll think you're a strange OCD type, but won't probe more deeply. Meanwhile, you get the benefit of knowing that you've not got physical keyloggers installed (and you know you've not installed malware on it, yes?)
I agree that big data is often crazy big. I wonder how some of this data is even moved around. 60 gigabits sounds amazing. But if the system is set up with map reduce or other cool tap into the data often something can be simply crafted that will produce stunningly useful data.
It all depends. The data is often very large at the point of collection and between there and the first point of analysis; it's only after that point that you can start to get the quantities down to a saner level. Even then it remains hard to ensure that you can actually search the data; you don't want the data to just sit there, you want to be able to do something useful with it. Yes, you can try putting some sort of tap on it as it is flowing past, but then you're always wondering whether you're monitoring the right thing; you might be ignoring something critical and you'd never know.
The Big Data trend is about capturing all of the data (or a much larger fraction than before) and looking through what you've got afterwards. Some of this is done with the like of Hadoop, some with commercial software. There are both SQL and NoSQL DBs in the mix. And more than a few python scripts I'd be willing to bet. (This is all independent of where the data is actually stored; that depends on the particular application, but you don't get into this sort of thing without thinking carefully about what you're doing. The physical constraints on moving that much data around mean you can't blunder in without a clue.)
If anything's going to kill Facebook, it will be decisions made by people who were only hired to make money. People who have no interest in what it's for, never will have interest, and are only there to monetize.
Yes and no; if the company doesn't make money then it is still in trouble. The hard part is that you've got to have both passion to deliver a good product/service and monetization of that so that you can afford to keep doing it, and a lot of companies find that very difficult.
It's feeling like one of those stocks that will eventually hit a $1 or less.
What's with the US fixation with whether the unit price of some particular stock is less than $1, when it's something you wouldn't normally hold just one of? Surely the price of a single unit doesn't matter too much; what matters is how much that value is when you multiply it by the total number of stocks (either in your holding or in the overall company, depending on what you're talking about).
Or is there some regulation that I don't know about (not being a US citizen or based in the US)?
They are suing because they believe that Google, Samsung, etc truly stole their ideas to make phones.
The problem is that the real innovation was that you can make a profit selling smartphones with a touch screen, and that's really difficult to patent. Particular details can be patented, but they can also be worked around. (The patent system deliberately encourages this.)
Apple may not be winning in market share, but they're KILLING IT in profits
Profits say how you did, not how you're going to do in 6 months time. Very large profits for a producer indicate that there's a market opportunity for other producers to come in and sell cheaper alternatives; those other producers will make less profit, but can greatly reduce the total amount of profit that the former market leader was making.
And if this isn't covered by standard market theory that's been around for many decades, I'll be very surprised!
Yeah... and BMW is about to go out of business if they don't expand from their single-digit market share. I think they'll be able to sustain a niche market with their margins, they always have.
Yes and no. Apple should be able keep going as a profitable niche player (which is what BMW is in the automobile market). The problem is that the network effects of the ecosystem of providers and having a high-end product that lots of people really wanted to buy will dissipate; the super-profitability that came with that will not last.
Call it the free market improving the efficiency for customers...
Second is that while Android sells more handsets, there is a clear profit disparity between the two. They aim at different markets to some degree, but Apple is share of profits is more than merely disproportionate. This could mean Android phones can't sell at the same prices, that there are just tons more Android phones eating what used to be the feature phone market (my guess by far), or just that handset makers are cramming as much hardware as they can afford to differentiate themselves.
My guess is that a much larger fraction of the profits are going to the carriers, which encourages them to push the Android devices to their customers. The customers don't really care one way or the other, but the carriers do. After all, why plug a device that earns you a few bucks a year net when you can get them to buy something that does roughly the same (and at a similar price) but where you get ten or a hundred times more profit? What's more, such a model encourages every carrier to push high-end smartphones, so the number of users will be much higher, and the number of apps will be much higher as they'll follow the users, and the media providers will also follow the users. Apple's profitability might be great, but the wheels are in danger of coming off their ecosystem. It's not helped by the relatively short lifespan of these mobile devices; users are not locked in for half a decade and nor are devs or content providers.
Try doing 1080p real time video over SSH, and manipulate it and you'll notice some lag.
So you're going to claim that GUIs cannot possibly work over networks because you can't stream 3Gbps over the open internet in a sustained fashion without hitting some problems with bandwidth and latency? Hmm...
Have you any actual experience with a networked server?
Yes. That's the day job.
The real problem is that you go from a situation where all components can talk to each other quickly to a situation where everything you do must be carefully analysed because each time you cross the boundary between local and remote you take a possibly big hit from latency and possibly also bandwidth if it's a lot of data.
Yes, but you've also got to handle the fact that you're in potentially-different security domains. That's where things get much trickier because you can't necessarily put the code where it makes things fastest. (Sandboxing technologies have come a long way, but it's still a real worry.) It's also the case that any solution for the remote case probably ought to be applied to the local case too.
I have a Master's degree in distributed systems, and the mere term "network-transparent" is probably a fallacy. In face of the huge performance implications of a network, the local-remote split most likely has to be explicit in some way, just like it is with web. Unless you don't crappy performance.
You the verb there. Just sayin'...
"Network-transparent" is a lie. You can't conceal their presence. (See NFS and SMB/CIFS for examples of leakiness of abstractions.)
http://wayland.freedesktop.org/screenshots.html
Is it just me or do some of those screenshots show significant rendering bugs like a failure to erase text correctly? (That's in the VTE demo.) Aside from that, are there any impressive demos?
Similarly X has 30 year history of really really doing a bad job of delivering a smooth GUI experience. That while in theory the network protocol shouldn't cost much, in practice it often seems to complicate design tremendously. X supporters IMHO and experience have trouble often admitting how many GUI projects fail or take 10x longer than they should because of the complexity of working with the X / multiple window manager / multi GUI stack.
That's an interesting assertion you're making there, that supporting a networked protocol causes excessive complication in the server. Would you care to provide (or point to) some evidence for that?
In my experience, the hard parts of making GUI code are dealing with multiple platforms (why would you want to write code for a single platform?) and going from functional-but-dull to snazzy-and-usable. The networking side of things (or not) is nowhere on that map.
you already generally have to use something like VNC or xpra (layered over X, not really using it) in order to get reasonable performance or to detach and reattach remotely.
X might seem like the answer until you try to use it... it isn't good enough because it's nowhere near usable as GNU screen.
Quite apart from the fact that terminals are a heck of a lot simpler than a GUI system, there are plenty of cases where high performance and detaching simply aren't needed. So what if the program goes away when you close the connection? You can run it again when you connect again, no problem. That's worked fine for all the cases in the past 5 years where I've needed remote X (such as installing engineering simulators or running certain types of performance monitors).
But the fact that you're comparing X11 to screen merely indicates that you're an insightless noob. Me? There's a lot about X11 that I don't like and there are some design decisions that are starting to look like really bad limitations, but that's because I've actually written toolkit code that uses X11; I know where many of the bodies are buried. Yet instead of kicking at the open door, you're trying to attack X11's strengths.
Numerical Methods will teach you exactly when and why rounding errors to happen, how they can compound each other, and in general help you write squeeky-clean math code.
Numerical methods is the course that all programmers should take and hardly any do (or at least not and think about what they've learned afterwards).
The one discipline that you don't mention that you perhaps should have done is logic. Programmers tend to be very good at logic, as programs are always logical constructions. A working programmer will deal with logic (especially boolean logic) day in, day out for years, so knowing what's going on with it will help a lot. I suppose programmers mostly think it's obvious and so forget to mention it...
Logic is math, and EVERYONE needs logic.
Serious logicians say that math is a branch of logic (just like physics is a branch of math, chemistry a branch of physics, etc.) Serious philosophers say that logic is a branch of their discipline. Myself, I recommend math in school because it helps you think in an organized way, and that's ever so useful whatever you're doing with your life.
Well, unless your life plan is to sit around at home in your underpants eating cold instant ramen while watching Star Trek marathons.
The one difference is that truth is considered a defense in the U.S. while in the U.K. it can still be considered irrelevant.
The main difference there is that something being true doesn't mean that you have a right to say it; certain parts of the truth are still unreasonable and harmful to say. Something being the truth does shift the onus much more strongly towards the plaintiff to show that it shouldn't have been said though. It doesn't come up very often, to be honest.