My university appears to filter everyone, even the IT department.
That's because only the desktop machines of the "Inner Circle" will be whitelisted, and that certainly won't be the whole of IT. There will be explicit exceptions in the firewall rules for specific source IP addresses. (One of the exceptions will have to be for the proxy itself, though that could be DMZed. That would be genuinely competent, but unexpected.)
I have this at work. get your sshd to listen on 443. if they manage to block that, start a petition. DPI is evil.
You underestimate how tricky things could be. They might just block 443 anyway, which wouldn't be DPI but would be vastly annoying. Yes, it breaks sites thoroughly. Some might be white-listed (though the whitelist is likely to be out of date).
Just for comparison: I've had meetings in places where the only external internet at all was via a crusty old proxy that couldn't even cope with the CONNECT verb and which would only allow you to reach port 80 in the first place. Not that it was worth trying to route around at all in the end; the bandwidth was awful and the latency in the multi-second range. Horrible horrible network. (There was another place that was nearly as bad until I had a word with their network guy and he told me the password for their external wifi; he was worried that it had no firewall in place to protect me, but I told him that I'd run my own security and handle the consequences. I was the only person who had good networking in the whole building.:-))
This case is also complicated by the possible twist that the Shenzhen company was in the hands of the receivers from March 2009 - sale of assets is not allowed without the approval of the creditors (prevent asset stripping) - see link in one of my previous posts.
That's a good point. However, in that case, the creditors can go after Proview for illegally selling something. Proview doesn't have standing. A valid contract was put together and the property was sold.
But you can't sell something you don't have the right to sell. That's a very basic feature of commercial law. Was the particular transaction in question valid? No idea. Let the court (or rather courts in several jurisdictions; this is complicated!) figure this out.
WHAT!! Like Wyoming but with less people!!!!!! SIGN ME UP! I'll take 500 acres to homestead, please.
I see you're after a small place there. (Most of Canada is terribly empty, unless you like tundra, trees, bogs and snow/biting insects, depending on season. Lots of northern Europe and Asia is identical and hardly anyone lives there either.)
The simplistic answer is that fee companies competing with state-sponsored ones is by very definition not a free market.
So... Libertarianism only works if China is Libertarian as well? Oooh... kaay... but I do think this is a good time to deploy "Good Luck With That" and some hollow laughter. Seriously, a politico-economic model that only works when everyone plays by the same set of rules is definitely unworkable in reality. It's like the right-wing reverse-image version of Communism. Sure, the nature of the mistakes it makes are different at the level of the detail, but the big picture is that you simply must not assume that people will obey any particular rule. There's always going to be someone (or some country or some company or... well, who isn't important) willing to be underhanded to gain an advantage.
Each generation has its peculiar fashions and prejudices.
Even the word "generation" is prejudicial. It assumes there's some massive sea change, a moment when everyone born after thinks and acts in a different way. That's just totally BS. Reality's one big mess of stuff, with its early adopters, bellwethers and luddites. The same person may even be in all of those categories simultaneously (though for different things).
It exists. It's twenty years old. It doesn't require marshalling. It allows object-oriented components to be reused in almost any language. It's in-process COM.
It has a butt-load of problems in that it requires particular models of type systems and memory management. It's also a problem with respect to security boundaries. Managed code systems such as Java or C#/.Net do better (within their restrictions) and you actually do see a lot of code reuse in the wild now.
The deep problem doesn't go away though: a good reusable component needs a properly considered API. You can't count on just use a chainsaw on some poor program and get a nice set of organs, ready to transplant. You're much more likely to end up with a bloody mess...
Some map companies, such as Streetmap or Multimap, would counter that point, arguing loudly that Google unfairly drove them out of business (or to a significantly lower level of business) by promoting Google Maps over their services via search, in breach of EU competition law.
I used to use Multimap when finding locations in cities before my first visit to them (little things like hotels, stations, where my conference/business meeting was going to be, etc.) and I found it to be a useful service. However, I switched to using Google not because of any cross-promotion with search, but rather because Google's service was significantly better. It was faster, it used more of the screen, it was more usable in general. Could Multimap have competed? I don't see why not, but they seemed at the time to be technologically resting on their laurels, making it easy for Google's better service to steal their lunch.
The moral of this? Nobody owes you a living. Keep up!
That's not true once you get to a certain size. If your company considers IT and storage to be a cost, then yes, a third party (where storage is their revenue source) will do it better. If your company considers IT and storage to be an investment, then they can do it just as good (if not better) than a third party.
It's not really to do with size, but rather to do with "core competencies". Small firms tend to only have a narrow range of things that they consider to be their secret sauce, and that usually doesn't include IT (excluding IT firms of course). Larger companies start to include IT as part of what they know how to do well, just as they also know a reasonable amount about HR and finance.
The other thing that drives clouds is the cost of a datacenter; a large one is a huge investment, and even big organizations might well prefer to avoid that sort of capital expenditure if not strictly necessary. At that end of things, there's a lot of similarity between clouds and more traditional IT outsourcing. The key is the nature of the contracts involved, and not everybody is the same there.
Twenty times stronger then steel sounds strong until you realize they're talking about a cable far a lot longer then 20 times longer then what you'd ever consider making out of steel. As such, while 20 times is great... it's probably at least a thousand times too weak.
It's not really a cable. More like the structural component, in that the main thing it has to support is its own weight. You put the motors in the lift cars and they crawl up and down the "cable".
They teach M to us at school but kilometers are more convenient than meters for long distances so we think about a 1,000 km flight and never think about a 1 Mm one. In all my life I think I used M only for Mega bytes. The common units for distances are mm, cm, m and km. Anything else is used almost only by professionals in their own fields of activity.
I'm fond of the megabuck as a unit of currency (symbol: M$). I'd be even more fond of it if I had one, but even so. (Of course, high finance these days seems to be measured in G$ and T$...)
With regard to the radiotelescope, the US doesn't have any suitable noise free sites.
It's also in the northern hemisphere, which has already been well studied. Yet the majority of really interesting objects (notably including the center of our galaxy) are in the southern sky. There's no particular reason for this — it's pure happenstance — but it does mean that we want a good radiotelescope well south of the equator. (To be fair, Hawaii's probably far enough south for many of the interesting targets and the ocean surrounding it really isn't that radio-noisy, but it's not large enough for an instrument like the SKA. It's planned scale is really brain-boggling.)
Except that not everyone who sells free software is doing so as part of a commercial venture; free software may be sold at a break even price by a nonprofit or by volunteers (e.g. as part of a kit for running an installfest).
That particular argument is void. If there's money changing hands, it means that it is possible to collect royalties; they just increase the break even price. (Current systems for dealing with such things might make it not practical, but that's an implementation problem.)
I don't like software patents, but I hate people arguing against anything with crappy reasoning!
Compiling any >8 bit per character language is painful because of more complex string processing.
It's only truly painful if you've mistaken a group of 8 bits for a character and if you've got a poor string library. If you're struggling still, you're using the wrong language. (Now, supporting multiple languages and locales in a single program is more painful because there's so many ways things differ and so many ways to hard-code assumptions.)
^^^ This! And once you have your UI sketched on paper, you could use Qt (with or without Quick) to implement it.
Except the user interface proposed will almost certainly not work well because the user who designed it won't understand about GUI design. Not that it's their fault; it's a discipline all of its own. Expect to iterate many times. Whatever you use had better support rapid prototyping. Being able to interactively add things in and test them out will help (it cuts the cycle-time of iterations). Be aware that you might not discover major features until quite late in the process.
In other words, GUIs need you to be hyper-Agile during the early stages of development and you're proposing something disturbingly close to Waterfall...
The added benefit of these toolkits [Qt, wxWidgets] is that they're a lot more portable than Cocoa.
And the disadvantage is that they don't look or behave in a native way on OSX without lots more work. At the prototyping stage this doesn't matter (and for some users it never matters) but it becomes a major PITA when you're ramping up to the level of becoming a product.
I used to care about cross-platform development, but I don't now nearly so much. Platforms differ. It does make sense to make the core functionality independent of platform though. Sometimes that's best done by offloading that core to a server (under your desk, in your datacenter, in the Cloud, whatever) and sometimes by having a common library or language to implement the core, often a combination of the two. It really depends on what you're doing.
No one wants to use Native Client because it will tie the web to specific CPU architectures.
That's not as big a problem as you might think; there are only two CPU architectures that really matter. All you need is a way to deliver an appropriate client for whether the code will be running on x86 (or derivative) or ARM. A tiny extension to the content negotiation headers that HTTP already sends and you're golden. (If your code is clean, delivering to multiple CPU architectures is not difficult. Especially if your toolchain can build all of them at the same time. And simulators exist for testing of non-performance-critical parts.)
In short, it should be trivial to make the normal-developer parts easy. The hard part will be getting a good port of the sandboxing and ensuring that there's a good enough and secure API back into the browser. Those are the parts that a normal developer wouldn't work on.
Reducing the supply voltage is the main vehicle to reduce power consumption, but with standard CMOS you run into the problem that transistors leak a little current when they're run at or near the threshold voltage because they don't turn off completely (you need significantly more than the threshold voltage for that.)
Of course they do; CMOS transistors are analog circuit components. Yes, usually they're driven into a state where their non-linearity makes them behave almost like binary components, but they're very much not that. The closer you drive them to the limit, whether through raising the speed or through lowering the voltage, the more they behave like the analog devices they truly are.
Strange you also would like to use goto. Even in 1968 Dijkstra considered this harmful in a famous paper - so generally anyone wanting to use this is considered slightly deranged, there are alternatives that are much more maintanable. So railing against Java for a construct that the consensus considers bad form could also be seen as bad form (or an unawareness of just how bad designs that need goto are).
Actually, what Dijkstra was railing against in that paper (I'll assume you've also read Knuth's response to it) was the tendency of some developers to use goto to create patterns that didn't match what we now call structured programming. Of course, what has happened since then is that the set of structured idioms has expanded (notably including exceptions and try-with-resources) so that there is far less need for a raw goto. The main thing that isn't handled particularly well as yet is a state machine (though you can hack it with a switch in a loop). But if there's some pattern that still needs a direct goto, it should be characterized so that a higher-level pattern can be created.
At the low level it's all gotos, but they're generated by software so Dijkstra wouldn't have minded them at all.
Getting good performance in Java really requires knowing about StringBuilder (unless you're not doing anything much at all with strings). That's because the compiler changes this:
s += "the quick " + "brown " + fox + " jumps " + over;
Into this:
s = new StringBuilder(s).append("the quick brown ").append(fox) .append(" jumps ").append(over).toString();
The adjacent constants are combined into one, and the variable parts are done as separate calls to append(). (The old-style StringBuffer has the same interface, but with added locking for if you want to use it in multiple threads at once or make things run slower for no good reason.) This matters because if you're building up a string in a loop — a very very common thing I find — then you're better off putting the creation of a StringBuilder before the loop and the reconversion to string afterwards. This helps hugely because StringBuilder uses an amortized-constant-time string growth strategy so those appends are pretty cheap (the loop will be of linear cost), whereas if you're converting back and forth to a string you've killed that and turned the loop into quadratic cost (plus all those object allocation costs too). With nested loops, the cost goes up of course.
The long and short of it is this: if your Java program is slow, check for problems in string construction. They're easy to fix and even vaguely intelligent use of StringBuilder will speed things up.
In many cases the difference between Java and C++ performance, especially startup time, can be huge.
Quite apart from the fact that there are applications where startup time really isn't very important, it's important to emphasize that it is possible to write bad code in any language. It's certainly possible to do bad code in both Java and C++. It should be possible for the best of C++ code to beat the best of Java code, but it will be quite difficult to reach that level with either language (both are quite subtle in places) and good code in either will beat bad code in either. (Choosing a good algorithm is still important, folks!)
The weird thing is that I've found some utilities definitely written in Java still start up very quickly; there's obviously some costs there that most apps are paying which they shouldn't be.
Slashdot Mirror
My university appears to filter everyone, even the IT department.
That's because only the desktop machines of the "Inner Circle" will be whitelisted, and that certainly won't be the whole of IT. There will be explicit exceptions in the firewall rules for specific source IP addresses. (One of the exceptions will have to be for the proxy itself, though that could be DMZed. That would be genuinely competent, but unexpected.)
I have this at work. get your sshd to listen on 443. if they manage to block that, start a petition. DPI is evil.
You underestimate how tricky things could be. They might just block 443 anyway, which wouldn't be DPI but would be vastly annoying. Yes, it breaks sites thoroughly. Some might be white-listed (though the whitelist is likely to be out of date).
Just for comparison: I've had meetings in places where the only external internet at all was via a crusty old proxy that couldn't even cope with the CONNECT verb and which would only allow you to reach port 80 in the first place. Not that it was worth trying to route around at all in the end; the bandwidth was awful and the latency in the multi-second range. Horrible horrible network. (There was another place that was nearly as bad until I had a word with their network guy and he told me the password for their external wifi; he was worried that it had no firewall in place to protect me, but I told him that I'd run my own security and handle the consequences. I was the only person who had good networking in the whole building. :-))
This case is also complicated by the possible twist that the Shenzhen company was in the hands of the receivers from March 2009 - sale of assets is not allowed without the approval of the creditors (prevent asset stripping) - see link in one of my previous posts.
That's a good point. However, in that case, the creditors can go after Proview for illegally selling something. Proview doesn't have standing. A valid contract was put together and the property was sold.
But you can't sell something you don't have the right to sell. That's a very basic feature of commercial law. Was the particular transaction in question valid? No idea. Let the court (or rather courts in several jurisdictions; this is complicated!) figure this out.
Remember, buy low, sell high. You may have to wait for the high and resist selling in a panic.
Yes, but markets can be irrational for much longer than you have the money to keep up.
WHAT!! Like Wyoming but with less people!!!!!! SIGN ME UP! I'll take 500 acres to homestead, please.
I see you're after a small place there. (Most of Canada is terribly empty, unless you like tundra, trees, bogs and snow/biting insects, depending on season. Lots of northern Europe and Asia is identical and hardly anyone lives there either.)
The simplistic answer is that fee companies competing with state-sponsored ones is by very definition not a free market.
So... Libertarianism only works if China is Libertarian as well? Oooh... kaay... but I do think this is a good time to deploy "Good Luck With That" and some hollow laughter. Seriously, a politico-economic model that only works when everyone plays by the same set of rules is definitely unworkable in reality. It's like the right-wing reverse-image version of Communism. Sure, the nature of the mistakes it makes are different at the level of the detail, but the big picture is that you simply must not assume that people will obey any particular rule. There's always going to be someone (or some country or some company or ... well, who isn't important) willing to be underhanded to gain an advantage.
Each generation has its peculiar fashions and prejudices.
Even the word "generation" is prejudicial. It assumes there's some massive sea change, a moment when everyone born after thinks and acts in a different way. That's just totally BS. Reality's one big mess of stuff, with its early adopters, bellwethers and luddites. The same person may even be in all of those categories simultaneously (though for different things).
It exists. It's twenty years old. It doesn't require marshalling. It allows object-oriented components to be reused in almost any language. It's in-process COM.
It has a butt-load of problems in that it requires particular models of type systems and memory management. It's also a problem with respect to security boundaries. Managed code systems such as Java or C#/.Net do better (within their restrictions) and you actually do see a lot of code reuse in the wild now.
The deep problem doesn't go away though: a good reusable component needs a properly considered API. You can't count on just use a chainsaw on some poor program and get a nice set of organs, ready to transplant. You're much more likely to end up with a bloody mess...
Some map companies, such as Streetmap or Multimap, would counter that point, arguing loudly that Google unfairly drove them out of business (or to a significantly lower level of business) by promoting Google Maps over their services via search, in breach of EU competition law.
I used to use Multimap when finding locations in cities before my first visit to them (little things like hotels, stations, where my conference/business meeting was going to be, etc.) and I found it to be a useful service. However, I switched to using Google not because of any cross-promotion with search, but rather because Google's service was significantly better. It was faster, it used more of the screen, it was more usable in general. Could Multimap have competed? I don't see why not, but they seemed at the time to be technologically resting on their laurels, making it easy for Google's better service to steal their lunch.
The moral of this? Nobody owes you a living. Keep up!
Science doesn't "say" anything. Stop anthropomorphizing things.
Yeah. Science hates being anthropomorphized. It gets all upset and goes off to sulk in a corner.
That's not true once you get to a certain size. If your company considers IT and storage to be a cost, then yes, a third party (where storage is their revenue source) will do it better. If your company considers IT and storage to be an investment, then they can do it just as good (if not better) than a third party.
It's not really to do with size, but rather to do with "core competencies". Small firms tend to only have a narrow range of things that they consider to be their secret sauce, and that usually doesn't include IT (excluding IT firms of course). Larger companies start to include IT as part of what they know how to do well, just as they also know a reasonable amount about HR and finance.
The other thing that drives clouds is the cost of a datacenter; a large one is a huge investment, and even big organizations might well prefer to avoid that sort of capital expenditure if not strictly necessary. At that end of things, there's a lot of similarity between clouds and more traditional IT outsourcing. The key is the nature of the contracts involved, and not everybody is the same there.
Twenty times stronger then steel sounds strong until you realize they're talking about a cable far a lot longer then 20 times longer then what you'd ever consider making out of steel. As such, while 20 times is great... it's probably at least a thousand times too weak.
It's not really a cable. More like the structural component, in that the main thing it has to support is its own weight. You put the motors in the lift cars and they crawl up and down the "cable".
They teach M to us at school but kilometers are more convenient than meters for long distances so we think about a 1,000 km flight and never think about a 1 Mm one. In all my life I think I used M only for Mega bytes. The common units for distances are mm, cm, m and km. Anything else is used almost only by professionals in their own fields of activity.
I'm fond of the megabuck as a unit of currency (symbol: M$). I'd be even more fond of it if I had one, but even so. (Of course, high finance these days seems to be measured in G$ and T$...)
With regard to the radiotelescope, the US doesn't have any suitable noise free sites.
It's also in the northern hemisphere, which has already been well studied. Yet the majority of really interesting objects (notably including the center of our galaxy) are in the southern sky. There's no particular reason for this — it's pure happenstance — but it does mean that we want a good radiotelescope well south of the equator. (To be fair, Hawaii's probably far enough south for many of the interesting targets and the ocean surrounding it really isn't that radio-noisy, but it's not large enough for an instrument like the SKA. It's planned scale is really brain-boggling.)
Except that not everyone who sells free software is doing so as part of a commercial venture; free software may be sold at a break even price by a nonprofit or by volunteers (e.g. as part of a kit for running an installfest).
That particular argument is void. If there's money changing hands, it means that it is possible to collect royalties; they just increase the break even price. (Current systems for dealing with such things might make it not practical, but that's an implementation problem.)
I don't like software patents, but I hate people arguing against anything with crappy reasoning!
Biologists. Sure they could program.
I work with biologists. It's a very rare one that can program. Rarer still that they can program efficiently.
Compiling any >8 bit per character language is painful because of more complex string processing.
It's only truly painful if you've mistaken a group of 8 bits for a character and if you've got a poor string library. If you're struggling still, you're using the wrong language. (Now, supporting multiple languages and locales in a single program is more painful because there's so many ways things differ and so many ways to hard-code assumptions.)
^^^ This! And once you have your UI sketched on paper, you could use Qt (with or without Quick) to implement it.
Except the user interface proposed will almost certainly not work well because the user who designed it won't understand about GUI design. Not that it's their fault; it's a discipline all of its own. Expect to iterate many times. Whatever you use had better support rapid prototyping. Being able to interactively add things in and test them out will help (it cuts the cycle-time of iterations). Be aware that you might not discover major features until quite late in the process.
In other words, GUIs need you to be hyper-Agile during the early stages of development and you're proposing something disturbingly close to Waterfall...
The added benefit of these toolkits [Qt, wxWidgets] is that they're a lot more portable than Cocoa.
And the disadvantage is that they don't look or behave in a native way on OSX without lots more work. At the prototyping stage this doesn't matter (and for some users it never matters) but it becomes a major PITA when you're ramping up to the level of becoming a product.
I used to care about cross-platform development, but I don't now nearly so much. Platforms differ. It does make sense to make the core functionality independent of platform though. Sometimes that's best done by offloading that core to a server (under your desk, in your datacenter, in the Cloud, whatever) and sometimes by having a common library or language to implement the core, often a combination of the two. It really depends on what you're doing.
No one wants to use Native Client because it will tie the web to specific CPU architectures.
That's not as big a problem as you might think; there are only two CPU architectures that really matter. All you need is a way to deliver an appropriate client for whether the code will be running on x86 (or derivative) or ARM. A tiny extension to the content negotiation headers that HTTP already sends and you're golden. (If your code is clean, delivering to multiple CPU architectures is not difficult. Especially if your toolchain can build all of them at the same time. And simulators exist for testing of non-performance-critical parts.)
In short, it should be trivial to make the normal-developer parts easy. The hard part will be getting a good port of the sandboxing and ensuring that there's a good enough and secure API back into the browser. Those are the parts that a normal developer wouldn't work on.
Reducing the supply voltage is the main vehicle to reduce power consumption, but with standard CMOS you run into the problem that transistors leak a little current when they're run at or near the threshold voltage because they don't turn off completely (you need significantly more than the threshold voltage for that.)
Of course they do; CMOS transistors are analog circuit components. Yes, usually they're driven into a state where their non-linearity makes them behave almost like binary components, but they're very much not that. The closer you drive them to the limit, whether through raising the speed or through lowering the voltage, the more they behave like the analog devices they truly are.
Strange you also would like to use goto. Even in 1968 Dijkstra considered this harmful in a famous paper - so generally anyone wanting to use this is considered slightly deranged, there are alternatives that are much more maintanable. So railing against Java for a construct that the consensus considers bad form could also be seen as bad form (or an unawareness of just how bad designs that need goto are).
Actually, what Dijkstra was railing against in that paper (I'll assume you've also read Knuth's response to it) was the tendency of some developers to use goto to create patterns that didn't match what we now call structured programming. Of course, what has happened since then is that the set of structured idioms has expanded (notably including exceptions and try-with-resources) so that there is far less need for a raw goto. The main thing that isn't handled particularly well as yet is a state machine (though you can hack it with a switch in a loop). But if there's some pattern that still needs a direct goto, it should be characterized so that a higher-level pattern can be created.
At the low level it's all gotos, but they're generated by software so Dijkstra wouldn't have minded them at all.
It didn't provide my two essential statements label <label>: and goto <label>;.
What high-level structured-programming concept is missing such that you need those low-level primitives?
Getting good performance in Java really requires knowing about StringBuilder (unless you're not doing anything much at all with strings). That's because the compiler changes this:
s += "the quick " + "brown " + fox + " jumps " + over;
Into this:
s = new StringBuilder(s).append("the quick brown ").append(fox)
.append(" jumps ").append(over).toString();
The adjacent constants are combined into one, and the variable parts are done as separate calls to append(). (The old-style StringBuffer has the same interface, but with added locking for if you want to use it in multiple threads at once or make things run slower for no good reason.) This matters because if you're building up a string in a loop — a very very common thing I find — then you're better off putting the creation of a StringBuilder before the loop and the reconversion to string afterwards. This helps hugely because StringBuilder uses an amortized-constant-time string growth strategy so those appends are pretty cheap (the loop will be of linear cost), whereas if you're converting back and forth to a string you've killed that and turned the loop into quadratic cost (plus all those object allocation costs too). With nested loops, the cost goes up of course.
The long and short of it is this: if your Java program is slow, check for problems in string construction. They're easy to fix and even vaguely intelligent use of StringBuilder will speed things up.
In many cases the difference between Java and C++ performance, especially startup time, can be huge.
Quite apart from the fact that there are applications where startup time really isn't very important, it's important to emphasize that it is possible to write bad code in any language. It's certainly possible to do bad code in both Java and C++. It should be possible for the best of C++ code to beat the best of Java code, but it will be quite difficult to reach that level with either language (both are quite subtle in places) and good code in either will beat bad code in either. (Choosing a good algorithm is still important, folks!)
The weird thing is that I've found some utilities definitely written in Java still start up very quickly; there's obviously some costs there that most apps are paying which they shouldn't be.