I think the UK government is too eager by a large factor to be "digital by default" (also a buzzword of theirs) and in fact is willing to, well, lose control over most of their vital governmental services over it. And of course that involves shelling out yet more dosh to random corporations that look hip and big enough. So expect cost overruns shortly. The corporations on the government's shortlist generally aren't bereft of payment, no.
Agree with what? With creating convenient maps of information that's already somewhat public and therefore entirely public in the American No-Curtains-So-No-Privacy-For-You view? With protesting that convenient map? With taking revenge on the complainers by, er, dumping the adress of every permit holder whether they're part of the discussion or not?
There are a few issues here, not least of which is that this approach to privacy isn't tenable in the modern age with its proliferation of convenient data mangling apparatuses--even though there's a risk to trying to burgle a known gun owner. Or how exercising a constitution-enshrined right makes one a target--note that this trend in American Society[tm] bothers me independent of having that right, which I don't.
But what bothers me most is how the whole gun thing is again diving for the trenches. Much like how "seven bullets" is completely arbitrary, as is the labeling of some kinds of ammunition "cop killer", as are so many silly knee-jerk measures. As is the rallying "strategy" of the NRA, for that matter.
This isn't a mature discussion. And you're supposed to be the shining beacon of democracy for the whole world. All of you. Grow up.
Alright, not exactly dialup. But close enough for making the comparison on slashdot.
Should be interesting, trying not to make too much of a mess to avoid running the bots out of traffic allowance and/or running up the punters' bills enough to notice something is amiss.
I have considered brushing up java to sell to employers, as a copyright firewall between what I like to do and what they pay me to do. If you can stand it, and have a contract to suit, it might work.
A chance remark elsewhere pointed me to why xml and its various(!) query languages is so popular in certain places: It's easier to get things done in that than in java. So that meshes well with your experience. This is not to imply that xml is a good idea elsewhere.
As your interface to telling the computer what to do, various languages have their various upsides. I've been looking into python for quite a bit lately even though the community turned out to have a few nasty spots in it. Someone argued it's sort-of lisp in drag and it's certainly nice for a broad class of things to do with it. I didn't like ruby much but I can see where its appeal lies. Maybe just not my style. And if you'd like to try a lisp, go right ahead, though watch it for that road might lead to emacs. I also have a few things yet I'd like to try but no point in trying to do everything at once, eh.
To me, though, there is zero need to rely on the JVM. I'm much closer to the system (many hats, mostly unix family and friends) so I'm just as likely to write a shell or awk script. Or use C to glue things together, effectively using it as some sort of scripting language.
And some things I like to do in C++, though I'll also revamp a tool back to C if it turns out it didn't need any C++ features. Strict typing doesn't other me, though I recall disliking java's way. It's been a while. In fact, too loose typing and I start to feel I lose track of what was what again. But sometimes being able to just return whatever regardless of type is nice too.
Without STL you haven't really done C++, similarly you need some idea how and what for objects work best in C++. But then, apparently most "C/C++" is really just shitty C with some perfunctory C++ sauce. Boost is a bit too large to casually throw in (I've seen FOSS projects replace libsigc++ with requiring all of boost but using only a tiny part, as that was somehow undefinedly "better" or some malarky--it'd've saved everyone using the source quite a lot of bother to leave well alone), but it's quite useful as a baseline to prevent groups from reinventing the wheel too much, so for that sort of project familiarity with it is useful.
The bottom line is that it pays to know a few different languages so that you have a few choices picking whichever is most suitable for the problem or goal at hand.
So I can't really recommend anything specific to using the JVM; last time I had to use it, it involved having to have both 32 and 64bit windows versions so various 3rd party applets would function in a 32bit browser on top of the 64bit "OS", and then the whole holes oracle wouldn't or couldn't fix thing started. Glad I don't have to care for that any longer. Neither windows nor JVM here.
But if you have reason to want something that runs on top of JVM, well, no reason not to try something that isn't java but does run on the JVM.
The message was exactly to reduce the problem as much as possible to this static content serving thing as much as possible to make use of the solved-problem properties of that solution. For the smartest algorithm of all is the one that does the least amount of work: Nothing. So if you're bent on speed, it pays to move heaven and earth in development to make that algorithm applicable in practice.
"Most" websites these days burn cycles on dynamic content just because, and so they're leaving a lot of cycle savings on the table for "developer convenience" that may turn out to not be convenience at all--the logic needs maintenance too.
Similarly, plenty of sites are too free with client-side cycles again for "convenience", glossing over opportunities to offer a blazingly fast site with about the same effort, possibly less, that they're now sinking in creating things dynamically that really ought to've been created statically and served up as such. It's a related problem of needless wastage holding you down.
For someone sitting at a nice and fast client developing these things, it's easy to overlook the cost. But if you have millions of users with not quite the latest in hardware (a statistical inevitability, really) then you really should've made sure to not spend their cycles needlessly.
Up until this there's quite a lot to be gained in trivial fashion. Beyond that, the original question was an either/or dilemma that IMO isn't really germane to large scale either, because other approaches can crunch through more data faster. And with the small fry solved, you can spend your time optimising just the heavy bits to run as fast as you can get it in the available hardware.
And so we arrive at the conclusion: You want this either/or pick?
That pick really has nothing to do with speed. It has to do with what "enterprise ecosystem" you feel warmest and fuzziest at home with. So take your pick, and any time you run into problems you throw money at hardware and you assume the problems go away. Otherwise, well, neither is really suitable for the static content solved problem nor for scaling out to computationally hard problems.
If you come to the party with the preconception of having exactly these two options to choose from, then it really is that trivial. In that sense, you misread the point: I'm really saying that the given options suck and that there are better choices available outside the imposed solution space.
Well, I can run non-java stuff on JVM natively also. There's app-level providers and such these days (higher level abstraction), or I might consider an OS-VM as the container and truck those around (lower level abstraction). It's more an issue of if I have to have JVM somewhere (as in, I have to abstract at that level) then I'd still not simply settle on java because I have to have JVM.
There may be reasons, like corporate policies for example, why I'd have to have some VM thingy, and the upside of JVM is that there do exist multiple viable solutions from different sources. But since I'm not in that situation, the question of whether to use some VM, and then which one, comes last, not first.
Facebook chose to "invent" a php-to-C compiler because they couldn't rewrite the massive pile of php and they started to notice they needed more and more servers, and it's costing them. Sort of how sexchange setups need moar hardware than, oh, just about everything else. Sometimes to the tune of a large factor. Four quad-core xeon servers to run a bit of sexchange email? Same can be done with two dual-core xeons with some FOSS for OS and IMAP in front of a filer, with room to spare. For about ten times as many users.
Though from a management perspective, facebook probably made the right call there, as opposed to netscape that committed suicide by trying to start from scratch with nothing to tide them over. Where facebook certainly didn't make the right call was by using php in the first place. And, well, they're now content with their fancy php compiler contraption, and so won't move to something maintainable.
I think neither java nor c# are good choices in that first place either.
You want scale? Go simple. Serve static as much as you can. Use a fast, FOSS server. (For user-friendlyness, cut down on needless filching of cycles on that side too. Constructing css in js? Just serve up the css already, fool). Constructing that stuff? Eh, awk to do the markup tagging might be peachy fine in such a generate once, serve many times scenario. Or just about anything else you'd like to use. As long as you serve up static pre-generated html files with a fast server (kqueue, sendfile, memory filesystems if disk really is the bottleneck) and a suitable pipe to fill.
If I'd have to have something non-static I'd have a few interesting options at my disposal, and neither java nor c# would be near the top of the list. Or on the shortlist, for that matter.
If I'd have to have something non-static and I'd have to choose something running on top of a VM, well, the JVM has less problems with vendor-lock-in, though it's no panacea. But I'd look at some other language first. There are a few suitable alternatives that run on top of the JVM, so that's something to look at.
Java-the-language is too enterprise-y for my taste. Same with c#, and it's got more vendor lock-in sauce, no matter how their marketeering department likes to spin it. No, mono isn't really a viable alternative. And neither is serving up anything whatsoever with the vendor-native OS. That stuff just doesn't belong on the public internet.
What does enterprise-y mean? It means that the language is dumbed down for griding; for employing roomfuls of mediocre code grinders that are indeed cheaper when bought overseas (but that need more oversight and code auditing there--though it's a difference of degree only--and so are even more unsuitable for MBA-only managing). If you're going that route, the question of which is faster is pretty much moot: You're going at it brute force with the "human resources", so no excuse nor point, really, to not go the same route and buy more hardware, or hire ever larger chunks of your preferred supplier's cloud to serve up your fancy apps.
If that's what you care about, all you need is dosh to make the machine go. If it's something else, uhm, how did we arrive at this silly pseudo-dillemma again?
You sir, are sorely mistaken. I don't know what the proper name is for this rhetorical device so let's call it the defeatist's fallacy. You're certainly not the only one to spout it, but if you think about the implications you ought to be able to see where it goes awry and why it's such a devious thing to say.
It goes a little like this: Because an arbitrary someone already knows your name, the only sensible thing you can do is shout your name from the rooftops, tag it everywhere, and be sure that every single little thing you do has your only real name attached to it. Yes, this is hyperbole, but think about why it's such a silly thing to say. What you say is silly in a similar fashion.
People do have multiple identities even with a more or less identical name attached to it. Some of us have multiple identities with differing names attached to it. It does not follow that everyone must automatically pack all their identities together for combined inspection, even though facebook thinks that's really neat for making them money.
If you share your entire life on facebook, then yes, adding a nickname isn't going to help much. But if you don't, well, then having seperate accounts with different names attached might help. That you'll also have to block "like" buttons everywhere and never ever use facebook's "identity services" (mostly a data gathering vehicle) for other sites (or only for a well-defined set only used in the context of that nickname's identity), perhaps even need differing proxy services for different accounts, is besides the point. Even the fact that you can often datamine multiple identities together with high probability is besides the point. That it amounts to a false sense of security in some sense, well, since internet privacy enforcement is mostly law based so far, we can turn it into legally actionable security should we need to.
I do keep separate this account, for example. If you'd like, try and find a "real" name to go with it, report back here. Even text similarity analysis with the entire web will not help you much. If you go back far enough you might find enough leads for some good-old humint legwork, but purely electronically you'll have a challenge yet.
While datamining is getting ever cheaper and is already much more feasible than most people, even techies, are aware, does not mean that it is free, and with some effort you can make it expensive enough to not be worthwhile. Though really but a last refuge, you can try for being a thorougly uninteresting needle in a needlestack.
Your argument goes that because the choice is of no use for people who dump too much information into facebook (directly or indirectly) in the first place, it's okay to remove the choice for every user of facebook. And that, my dear zazzel, just doesn't fly.
And why is that? This is actually exactly how the CA structure was designed to work, not that commercial "we'll protect you from anyone we don't take money from"-crap, involving RAs and other unchecked entities that can use a CA to vouch for something that they haven't even checked themselves, a practice that somehow made it into the gold standard.
The DFN is the german academic research network, and so the guys running that network can vouch for every organisation connected to it. Each organisation is supposed to be able to vouch for the certificates they issue. What's your problem with that?
Personally, I think the whole PKI thing is FUBAR, since only one super is allowed to vouch for a sub and you're effectively forced to trust someone else's CA collection (down to a certain vendor silently undoing your changes to the store on your operating system come every update check). To make digital trust workable I, end user, have to be able to choose whom to trust, a choice I currently do not have, in fact cannot have lest my intarwebz stop functioning!
But in the case of the DFN, the hierarchy is exceptionally clear and one of the few places where it actually makes sense. And maintaining 200 sub-certificates is a lot less work than maintaining millions upon millions of certificates issued on a couple bucks and a grainy copy of your passport. What does that prove anyway?
The webmonkeys get hold of it. Do everything with it. They're ecstatic! Finally something that runs their javascript nice and fast!
So they throw more js into their webpages. Drop in a few more libraries, for their convenience. Of course, they're testing the stuff to the dev server that's at least as fast as the production server but sees only a small fraction of the load, and they have gigabit from desktop to server.
Thus, their websites become that much more crappy for everyone else, for everyone who doesn't have the lastest accellerator, or a nice and fast connection to an overspecced and mostly idle server.
It's happened before, it's happened again. Feh, if your desktop is old enough (single core, less than 2GHz these days) then between the crashes due to low memory you can actually notice when, say, jquery gets an update: Everything that uses it gets slower.
This is the state of websites, and as things stand, faster browsers mean slower websites for non-webmonkeys.
Ah-ha-ha! You wish failing kit would just up and die!
But really, you can't be sure of that. So things like ECC become minimum requirements, so you might at least have an inkling something isn't working quite right. Because otherwise, your calculations may be off and you won't know about it.
And yeah, propagated error can, and on this sort of scale eventually will, suddenly strike completely out of left field and hit like a tacnuke. At which point we'll all be wondering, what else went wrong and we didn't catch it in time?
To techies the idea seems absurd, but it's not. Sure, your server, your rules. But what you pull into them is another matter entirely, and the American view that if it's not behind closed curtains, it must be public, doesn't scale.
Compare, of all places, Japan, where it is in fact customary to "not see" things that are pretty much out in the open out of sheer necessity because too many people are living too close together. In a sense, the internet is worse than Tokyo.
There's irony here, where the techies are deriding politicians for doing boneheaded things with far too much data. Well, this is part of that, but in reverse, and if they're doing it wrong it's up to us to find ways to do it right and nudge them in the right direction.
DRM became a bad word because big media deployed it to control their customer whom had thought they'd bought something only the seller afterward pulled a legalised fast one. David losing to Goliath until dvdjon came along.
Data protection in this case wouldn't include money passing hands in the reverse direction. It's more like, well, you put DRM on your SSN when you sign up (and pay) for something that requires it, and you can more or less reliably wipe your SSN out of their databases once they no longer need it.
No longer having to trust some faceless large entity on their wooly word salad assurances and their pretty face is a nice boon for the individual. Bit of a different power balance there.
Yet the only real fix is to not store all that data in the first place. This means that a lot of data that's being gathered now must not be gathered at all or perhaps some other data needs to be gathered. Zero-knowledge proofs will likely have a big place in that, say to prove you're old enough without showing your ID card with all that extra data you're forced to give out currently. This'll need new techology, but will prove necessary to really scale out our data use without building databases of ruin.
Honestly, no, I'm not. If you keep confusing petty theft and murder you're not going to do much about the crime rate.
The threats are being named to perpetuate an indulgence racket where we should've switched vendors ages ago. We keep on cheapening out in favour of quick fixes that never seem to end up fixing much of anything. The risk to our systems is irrelevant in the face of our unwillingness to do what really needs to be done.
The IT security industry arguably is made out of oversimplification. It's like, cyber, you know?
Take, for example, the word "hacker". It's not enough to know you're one a them "hackers", you need to show what hat colour you wear. And even then it's not enough. Why? Because it's been so overused everyone got confused.
Do fishy things with computers? Hacker. Filch some access codes over teh intarwebz? Hacker. "Security researcher"? Hacker. Script kiddie? Hacker. Do fishy things while there's a computer tangentially involded somehow? Hacker. Place keyboard logger (physical)? Hacker. Do fishy things while there's a computer in the next room? Hacker. Obviously.
Where the word once indicated someone with great original skill, and in general ment moby technological creativity, requiring your respected fellows to give it to you, it now has become an epithet as easy as the FBI's "mail fraud" indictment: You get'em for free with whatever else you do. Notably "talk to a journalist", or even "be in the vague vicinity of a journalist hack's next piece".
That the term nevertheless got used in criminal legislation is telling of its devolution by overuse. And of legislators a bit too keen to not be seen as hopelessly behind the times.
APT is the latest way of this "IT security industry" full of "hackers" to show that they're down with the cyber, baby. Where "cyber" now-a-days is the clueless' way of saying intarwebbertoobz when they don't want to sound like complete hicks, or just sound officious, notably governments.
So I say the whole bunch of "hackers" is very cyber these days. Cyberhackers with their cyberwhite cyberhats. Selling us cyberprotection against cyberAPTs.
But hackers, they're not. Which is ironic, since hacking is just about the exact opposite of oversimplification. But then, these people don't do ironic. They're dead serious on selling you their definitions and their protection.
I'd prefer cash. Around here, though, it's actively being marginalised, in the name of "security", but it's actually shifting risks to me and costing me privacy and flexibility to boot.
It really doesn't matter who owns your wallet, as long as it's not you it means you're being shafted. And this is why we need truly electronic payment mechanisms, not just online, but in our wallets too.
The problem is that the people who can give you such a thing have a perverse incentive not to. This includes, but is not limited to, google.
FreeBSD and NetBSD have an ABI wrapper feature (aka "linuxulator" when wrapping linux) that let you translate syscalls for older versions of the same OS, or even different unixoid OSes. Add userland libraries from the original environment, and you can run the original app unchanged. As long as the application doesn't try and access hard-to-duplicate features, talk to hardware directly, that sort of thing. This gets you a modern and virtualisable OS that can run your old programs.
If there isn't a suitable ABI wrapper for your platform now, at least it could be added relatively easily. Possibly a long shot but at least it's an option to look into.
Virtualisation is great, but there are a few things that cause horrible chicken/egg problems if you virtualise them.
So I'd reserve at least two separate boxes to "do infrastructure". DNS, NTP, remote logging, trap receiving, bastion, and so on. You simply plunk a unix on them and put the individual services in jails or the local equivalent. Don't even need much in the way of performance, so any old 1U box will do fine. Heck, a soekris or an alix board will do. Those are short enough that you can stick'em in any old wiring closet too. Great for geographically dispersing.
If you're stumping up for infrastructure that can host hundreds of VMs, then of course that is enough capacity to also run "little boxes", but it'd be stupid to not also shell out the little extra to make your infrastructure robust, instead of risking hypervisor dependencies on not-yet booted VMs in your private cloud, or whatever you'd call it. "Seems to work" is not enough: Turn off the entire datacentre and then try and cold boot it, remotely. If it's fully virtualised including necessary basic supports, it'll take more time and trouble than if you don't virtualise the pillars on which you built up the rest.
If all I had was exactly two boxes, I'd still run NTP and local DNS next to the hypervisor, not under a guest. NTP in particular; I've had my fill of (windows) boxes claiming to be stratum two yet being off by two minutes because they only update once a week. Of course, on a virtualised unix it'll be much less, but I don't want to find out the hard way the VM distorted the timekeeping in unexpected ways later, so this is one thing that needs its own box. There are similar scenarios for the other basics, but I'll leave them as an exercise. The gains of virtualising, saving a bit on hardware and power, simply do not outweigh the trouble when you can least afford it.
I'm looking for a new desktop, and I found I had to re-assess my shortlist when I realised that the usual single core benchmarks not merely are equally cherry picked, but also are factory rigged in hard-to-compare ways. Notice that the balanced MP cherry picking is your contribution; I just said to not focus on single-core benchmarks only as there's 4 or 8 cores available. My requirements mean that MP is not unimportant, but sheer gaming prowess is.
What with the price, you ask? Perception. intel is sitting pretty so they can (and have) put prices at very neatly balanced gouching points whereas AMD has had a thorough trouncing in the press so they have to provide more perceived value this time round. The bulldozer failure may or may not have been alleviated with thread affinity mods in the OS, but even if they'd fix that now, the damage has been done. Point is: It doesn't need to be an engineering fail to require fixing through pricing drops.
Also note that AMD does drop prices over time, and intel pretty much hasn't for a while. intel can get away with keeping the prices up even with newer and presumably better parts appearing at the same marketing and pricing slots, AMD cannot. That's not all engineering, that's intel sitting pretty and AMD threading water.
First you say they're bringing an 8 core chip to compete with a 4 core chip. Fine. Then you complain the cores cannot keep up 1:1. So you're expecting AMD's chips to be twice as good as intel's to be able to compete.
That, of course, is rigging the test, and so is dishonest.
One could also say that with single cores not much worse than the competition, but double the number of cores, and a lower price to boot, you get better value. Moreso if you can make good use of the double number of cores.
And that's before considering that single-core benchmarks are entirely unrepresentative for multi-core performance thanks to various tricks like turbo core and turbo boost — that aren't 1:1 comparable so you'd have to do full, sustained benchmarks on all cores simultaneously to find out which delivers the most sustained instructions per second.
Meaning that AMD's offering takes more marketing footwork, but technically is not all bad. Not at all.
what reasons would be there to wait for the crime to happen?
The freedom to act must include the freedom to fuck up. (Though it does not imply immunity from consequences.)
So it depends highly on just what consequences you're proposing to attach to "detected pre-crime". If all you do is to "just happen" to appear on the scene, and in case of private property ask people to leave, then you can.
If you are proposing to impose sanctions on not-yet-commited "crimes", or even "merely" build tracking databases, then that means you've reduced freedom some more, in fact you've stooped to thought police. It means that the country in which this is deployed is no longer free.
On the other hand, stopping a crime that wouldn't have happened anyway has no negative repercussions for this person.
Does it not? I think that's terribly naïve for a regular reader here, in fact for anyone with an internet connection.
Plus, there is the issue that such systems do effect changes in behaviour; you're effectively making people the string puppets of the technology. I think that's putting the cart before the horse, so this is a class of things we simply really ought not want. In fact, we ought to not want these things.
Having worked on a project done in XML (XML-in-SOAP actually, for double the XML, without specifying where and how to switch to quoted-xml-in-xml input), sort-of, by people who obviously had no fscking clue about specifying anything, much less interop standards, I'm pretty sure that fixed-field ascii would've been a massive improvement over that steaming pile of crap.
There are very definite requirements to specifying interop formats, and the things XML imposes are almost completely orthogonal, making it not a solution for the problem it's supposed to solve.
What you need is people who understand what interoperability entails and how to specify it, in any format. Those are very rare, and none of them are at the W3C. Just read their specifications: They're incredibly one-sided, written entirely for the "website author", and not for the browser writer. No wonder no two browsers act entirely the same on identical input.
There's a big secret that most spec writers fail to grasp, but I'll let you in on it here: For a computer interop format to be of any use, you need both an encoder and a decoder. So, provide reference encoders and decoders along with the spec, so people can check their implementations.
Ideally also provide faulty input so that it may be rejected. For an even more advanced approach there are model checkers that take a state machine representing your protocol and tell you where it'll break down.
But fail to do even the most basic reference designing, and you get something that may never parse. As was the case with above "SOAP" project. XML actually seems to have worsened the interop hell, as well as made processing and storage requirements worse. So, on balance, it's snake oil.
I think it's time to review the provisions of the process. Of course, it's a valid argument that doing it all entirely by hand is a bit much work, the internet being rather large and all that. On the other hand, fully-automated "processing" yields too many false positives, and the rights-holders don't care because they want to avoid false negatives more, nevermind the damage it does to other people's trust in the DMCA, even in copyright.
So we need to give them an incentive to make them care. In the meantime, I'd propose to require all notices to be double-checked by hand. That is, you can use bots all you want, but someone must eyeball the requests before they're issued, at the very least. That, or simply no longer listen to any requests when, not if, some botted party generates too many "oi! that's not yours to take down!" complaints about their "take this down" complaints.
I think there should be a mechanism that loses you your rights to enforce the copyrights you're holding if you're abusing the enforcement mechanism, like by generating too many false positives, yes. "Running a bot that goes amok" counts as abusing. Three strikes, anyone?
There's also the multi-million deals that are made on the back on an envelope... or a beer mat.
Those tend to be the better deals.
As always, in business and in programming and most everywhere else, you really should only introduce complexity when absolutely necessary. excel is a deceptive tool in that regard, it puts a "simple" face on a large bag of unstructured complexity, and then goes about guessing about what it deigns your inputs should actually mean.
Of course, insisting on bespoke software just to "fix" the flaws in excel without understanding the domain or the problem the existing jumble "solves" is a guarantee for getting less done, because the thing is made opaque and inflexible.
But that doesn't mean excel was a good idea in the first place. At best you get poor, shoddy hacks out of it. Despite everything it does right in the eyes of the user. That last bit is important, sure. But it's also important that the solution not fall over at the first sign of trouble, that it gives you a real handle on the complexity and the problem, and for things that aren't one-offs (recall that "temporary" solutions generally outlive "permanent" ones) that the thing scales a bit, not just in size but also in time. As in, it doesn't fall over in obscure ways with the next, or the next, or the next version of the software. And ideally you'd be independent of a single vendor. All things for developers to figure out, I'm sure.
As well they should, because there's a reason excel is seen "inescapable", whether it would still be after a rigorous investigation or not. Well, not just one reason, but it's become ingrained, a habit, the go-to-tool. Even though most who know what computers can do agree that it's not a very good tool at all. It's just so... warm and fuzzy in the minds of the business and enterprise warm body. So. Let's get to it.
Slashdot Mirror
Some unspecified slice of a £25 million pie.
I think the UK government is too eager by a large factor to be "digital by default" (also a buzzword of theirs) and in fact is willing to, well, lose control over most of their vital governmental services over it. And of course that involves shelling out yet more dosh to random corporations that look hip and big enough. So expect cost overruns shortly. The corporations on the government's shortlist generally aren't bereft of payment, no.
That merely lists the main ingredients for what appears to be the gold standard for political discourse in the country. Including that last bit. Yes.
Agree with what? With creating convenient maps of information that's already somewhat public and therefore entirely public in the American No-Curtains-So-No-Privacy-For-You view? With protesting that convenient map? With taking revenge on the complainers by, er, dumping the adress of every permit holder whether they're part of the discussion or not?
There are a few issues here, not least of which is that this approach to privacy isn't tenable in the modern age with its proliferation of convenient data mangling apparatuses--even though there's a risk to trying to burgle a known gun owner. Or how exercising a constitution-enshrined right makes one a target--note that this trend in American Society[tm] bothers me independent of having that right, which I don't.
But what bothers me most is how the whole gun thing is again diving for the trenches. Much like how "seven bullets" is completely arbitrary, as is the labeling of some kinds of ammunition "cop killer", as are so many silly knee-jerk measures. As is the rallying "strategy" of the NRA, for that matter.
This isn't a mature discussion. And you're supposed to be the shining beacon of democracy for the whole world. All of you. Grow up.
Alright, not exactly dialup. But close enough for making the comparison on slashdot.
Should be interesting, trying not to make too much of a mess to avoid running the bots out of traffic allowance and/or running up the punters' bills enough to notice something is amiss.
I have considered brushing up java to sell to employers, as a copyright firewall between what I like to do and what they pay me to do. If you can stand it, and have a contract to suit, it might work.
A chance remark elsewhere pointed me to why xml and its various(!) query languages is so popular in certain places: It's easier to get things done in that than in java. So that meshes well with your experience. This is not to imply that xml is a good idea elsewhere.
As your interface to telling the computer what to do, various languages have their various upsides. I've been looking into python for quite a bit lately even though the community turned out to have a few nasty spots in it. Someone argued it's sort-of lisp in drag and it's certainly nice for a broad class of things to do with it. I didn't like ruby much but I can see where its appeal lies. Maybe just not my style. And if you'd like to try a lisp, go right ahead, though watch it for that road might lead to emacs. I also have a few things yet I'd like to try but no point in trying to do everything at once, eh.
To me, though, there is zero need to rely on the JVM. I'm much closer to the system (many hats, mostly unix family and friends) so I'm just as likely to write a shell or awk script. Or use C to glue things together, effectively using it as some sort of scripting language.
And some things I like to do in C++, though I'll also revamp a tool back to C if it turns out it didn't need any C++ features. Strict typing doesn't other me, though I recall disliking java's way. It's been a while. In fact, too loose typing and I start to feel I lose track of what was what again. But sometimes being able to just return whatever regardless of type is nice too.
Without STL you haven't really done C++, similarly you need some idea how and what for objects work best in C++. But then, apparently most "C/C++" is really just shitty C with some perfunctory C++ sauce. Boost is a bit too large to casually throw in (I've seen FOSS projects replace libsigc++ with requiring all of boost but using only a tiny part, as that was somehow undefinedly "better" or some malarky--it'd've saved everyone using the source quite a lot of bother to leave well alone), but it's quite useful as a baseline to prevent groups from reinventing the wheel too much, so for that sort of project familiarity with it is useful.
The bottom line is that it pays to know a few different languages so that you have a few choices picking whichever is most suitable for the problem or goal at hand.
So I can't really recommend anything specific to using the JVM; last time I had to use it, it involved having to have both 32 and 64bit windows versions so various 3rd party applets would function in a 32bit browser on top of the 64bit "OS", and then the whole holes oracle wouldn't or couldn't fix thing started. Glad I don't have to care for that any longer. Neither windows nor JVM here.
But if you have reason to want something that runs on top of JVM, well, no reason not to try something that isn't java but does run on the JVM.
The message was exactly to reduce the problem as much as possible to this static content serving thing as much as possible to make use of the solved-problem properties of that solution. For the smartest algorithm of all is the one that does the least amount of work: Nothing. So if you're bent on speed, it pays to move heaven and earth in development to make that algorithm applicable in practice.
"Most" websites these days burn cycles on dynamic content just because, and so they're leaving a lot of cycle savings on the table for "developer convenience" that may turn out to not be convenience at all--the logic needs maintenance too.
Similarly, plenty of sites are too free with client-side cycles again for "convenience", glossing over opportunities to offer a blazingly fast site with about the same effort, possibly less, that they're now sinking in creating things dynamically that really ought to've been created statically and served up as such. It's a related problem of needless wastage holding you down.
For someone sitting at a nice and fast client developing these things, it's easy to overlook the cost. But if you have millions of users with not quite the latest in hardware (a statistical inevitability, really) then you really should've made sure to not spend their cycles needlessly.
Up until this there's quite a lot to be gained in trivial fashion. Beyond that, the original question was an either/or dilemma that IMO isn't really germane to large scale either, because other approaches can crunch through more data faster. And with the small fry solved, you can spend your time optimising just the heavy bits to run as fast as you can get it in the available hardware.
And so we arrive at the conclusion: You want this either/or pick?
That pick really has nothing to do with speed. It has to do with what "enterprise ecosystem" you feel warmest and fuzziest at home with. So take your pick, and any time you run into problems you throw money at hardware and you assume the problems go away. Otherwise, well, neither is really suitable for the static content solved problem nor for scaling out to computationally hard problems.
If you come to the party with the preconception of having exactly these two options to choose from, then it really is that trivial. In that sense, you misread the point: I'm really saying that the given options suck and that there are better choices available outside the imposed solution space.
Well, I can run non-java stuff on JVM natively also. There's app-level providers and such these days (higher level abstraction), or I might consider an OS-VM as the container and truck those around (lower level abstraction). It's more an issue of if I have to have JVM somewhere (as in, I have to abstract at that level) then I'd still not simply settle on java because I have to have JVM.
There may be reasons, like corporate policies for example, why I'd have to have some VM thingy, and the upside of JVM is that there do exist multiple viable solutions from different sources. But since I'm not in that situation, the question of whether to use some VM, and then which one, comes last, not first.
Facebook chose to "invent" a php-to-C compiler because they couldn't rewrite the massive pile of php and they started to notice they needed more and more servers, and it's costing them. Sort of how sexchange setups need moar hardware than, oh, just about everything else. Sometimes to the tune of a large factor. Four quad-core xeon servers to run a bit of sexchange email? Same can be done with two dual-core xeons with some FOSS for OS and IMAP in front of a filer, with room to spare. For about ten times as many users.
Though from a management perspective, facebook probably made the right call there, as opposed to netscape that committed suicide by trying to start from scratch with nothing to tide them over. Where facebook certainly didn't make the right call was by using php in the first place. And, well, they're now content with their fancy php compiler contraption, and so won't move to something maintainable.
I think neither java nor c# are good choices in that first place either.
You want scale? Go simple. Serve static as much as you can. Use a fast, FOSS server. (For user-friendlyness, cut down on needless filching of cycles on that side too. Constructing css in js? Just serve up the css already, fool). Constructing that stuff? Eh, awk to do the markup tagging might be peachy fine in such a generate once, serve many times scenario. Or just about anything else you'd like to use. As long as you serve up static pre-generated html files with a fast server (kqueue, sendfile, memory filesystems if disk really is the bottleneck) and a suitable pipe to fill.
If I'd have to have something non-static I'd have a few interesting options at my disposal, and neither java nor c# would be near the top of the list. Or on the shortlist, for that matter.
If I'd have to have something non-static and I'd have to choose something running on top of a VM, well, the JVM has less problems with vendor-lock-in, though it's no panacea. But I'd look at some other language first. There are a few suitable alternatives that run on top of the JVM, so that's something to look at.
Java-the-language is too enterprise-y for my taste. Same with c#, and it's got more vendor lock-in sauce, no matter how their marketeering department likes to spin it. No, mono isn't really a viable alternative. And neither is serving up anything whatsoever with the vendor-native OS. That stuff just doesn't belong on the public internet.
What does enterprise-y mean? It means that the language is dumbed down for griding; for employing roomfuls of mediocre code grinders that are indeed cheaper when bought overseas (but that need more oversight and code auditing there--though it's a difference of degree only--and so are even more unsuitable for MBA-only managing). If you're going that route, the question of which is faster is pretty much moot: You're going at it brute force with the "human resources", so no excuse nor point, really, to not go the same route and buy more hardware, or hire ever larger chunks of your preferred supplier's cloud to serve up your fancy apps.
If that's what you care about, all you need is dosh to make the machine go. If it's something else, uhm, how did we arrive at this silly pseudo-dillemma again?
You sir, are sorely mistaken. I don't know what the proper name is for this rhetorical device so let's call it the defeatist's fallacy. You're certainly not the only one to spout it, but if you think about the implications you ought to be able to see where it goes awry and why it's such a devious thing to say.
It goes a little like this: Because an arbitrary someone already knows your name, the only sensible thing you can do is shout your name from the rooftops, tag it everywhere, and be sure that every single little thing you do has your only real name attached to it. Yes, this is hyperbole, but think about why it's such a silly thing to say. What you say is silly in a similar fashion.
People do have multiple identities even with a more or less identical name attached to it. Some of us have multiple identities with differing names attached to it. It does not follow that everyone must automatically pack all their identities together for combined inspection, even though facebook thinks that's really neat for making them money.
If you share your entire life on facebook, then yes, adding a nickname isn't going to help much. But if you don't, well, then having seperate accounts with different names attached might help. That you'll also have to block "like" buttons everywhere and never ever use facebook's "identity services" (mostly a data gathering vehicle) for other sites (or only for a well-defined set only used in the context of that nickname's identity), perhaps even need differing proxy services for different accounts, is besides the point. Even the fact that you can often datamine multiple identities together with high probability is besides the point. That it amounts to a false sense of security in some sense, well, since internet privacy enforcement is mostly law based so far, we can turn it into legally actionable security should we need to.
I do keep separate this account, for example. If you'd like, try and find a "real" name to go with it, report back here. Even text similarity analysis with the entire web will not help you much. If you go back far enough you might find enough leads for some good-old humint legwork, but purely electronically you'll have a challenge yet.
While datamining is getting ever cheaper and is already much more feasible than most people, even techies, are aware, does not mean that it is free, and with some effort you can make it expensive enough to not be worthwhile. Though really but a last refuge, you can try for being a thorougly uninteresting needle in a needlestack.
Your argument goes that because the choice is of no use for people who dump too much information into facebook (directly or indirectly) in the first place, it's okay to remove the choice for every user of facebook. And that, my dear zazzel, just doesn't fly.
And why is that? This is actually exactly how the CA structure was designed to work, not that commercial "we'll protect you from anyone we don't take money from"-crap, involving RAs and other unchecked entities that can use a CA to vouch for something that they haven't even checked themselves, a practice that somehow made it into the gold standard.
The DFN is the german academic research network, and so the guys running that network can vouch for every organisation connected to it. Each organisation is supposed to be able to vouch for the certificates they issue. What's your problem with that?
Personally, I think the whole PKI thing is FUBAR, since only one super is allowed to vouch for a sub and you're effectively forced to trust someone else's CA collection (down to a certain vendor silently undoing your changes to the store on your operating system come every update check). To make digital trust workable I, end user, have to be able to choose whom to trust, a choice I currently do not have, in fact cannot have lest my intarwebz stop functioning!
But in the case of the DFN, the hierarchy is exceptionally clear and one of the few places where it actually makes sense. And maintaining 200 sub-certificates is a lot less work than maintaining millions upon millions of certificates issued on a couple bucks and a grainy copy of your passport. What does that prove anyway?
The webmonkeys get hold of it. Do everything with it. They're ecstatic! Finally something that runs their javascript nice and fast!
So they throw more js into their webpages. Drop in a few more libraries, for their convenience. Of course, they're testing the stuff to the dev server that's at least as fast as the production server but sees only a small fraction of the load, and they have gigabit from desktop to server.
Thus, their websites become that much more crappy for everyone else, for everyone who doesn't have the lastest accellerator, or a nice and fast connection to an overspecced and mostly idle server.
It's happened before, it's happened again. Feh, if your desktop is old enough (single core, less than 2GHz these days) then between the crashes due to low memory you can actually notice when, say, jquery gets an update: Everything that uses it gets slower.
This is the state of websites, and as things stand, faster browsers mean slower websites for non-webmonkeys.
Ah-ha-ha! You wish failing kit would just up and die!
But really, you can't be sure of that. So things like ECC become minimum requirements, so you might at least have an inkling something isn't working quite right. Because otherwise, your calculations may be off and you won't know about it.
And yeah, propagated error can, and on this sort of scale eventually will, suddenly strike completely out of left field and hit like a tacnuke. At which point we'll all be wondering, what else went wrong and we didn't catch it in time?
To techies the idea seems absurd, but it's not. Sure, your server, your rules. But what you pull into them is another matter entirely, and the American view that if it's not behind closed curtains, it must be public, doesn't scale.
Compare, of all places, Japan, where it is in fact customary to "not see" things that are pretty much out in the open out of sheer necessity because too many people are living too close together. In a sense, the internet is worse than Tokyo.
There's irony here, where the techies are deriding politicians for doing boneheaded things with far too much data. Well, this is part of that, but in reverse, and if they're doing it wrong it's up to us to find ways to do it right and nudge them in the right direction.
DRM became a bad word because big media deployed it to control their customer whom had thought they'd bought something only the seller afterward pulled a legalised fast one. David losing to Goliath until dvdjon came along.
Data protection in this case wouldn't include money passing hands in the reverse direction. It's more like, well, you put DRM on your SSN when you sign up (and pay) for something that requires it, and you can more or less reliably wipe your SSN out of their databases once they no longer need it.
No longer having to trust some faceless large entity on their wooly word salad assurances and their pretty face is a nice boon for the individual. Bit of a different power balance there.
Yet the only real fix is to not store all that data in the first place. This means that a lot of data that's being gathered now must not be gathered at all or perhaps some other data needs to be gathered. Zero-knowledge proofs will likely have a big place in that, say to prove you're old enough without showing your ID card with all that extra data you're forced to give out currently. This'll need new techology, but will prove necessary to really scale out our data use without building databases of ruin.
Honestly, no, I'm not. If you keep confusing petty theft and murder you're not going to do much about the crime rate.
The threats are being named to perpetuate an indulgence racket where we should've switched vendors ages ago. We keep on cheapening out in favour of quick fixes that never seem to end up fixing much of anything. The risk to our systems is irrelevant in the face of our unwillingness to do what really needs to be done.
The IT security industry arguably is made out of oversimplification. It's like, cyber, you know?
Take, for example, the word "hacker". It's not enough to know you're one a them "hackers", you need to show what hat colour you wear. And even then it's not enough. Why? Because it's been so overused everyone got confused.
Do fishy things with computers? Hacker.
Filch some access codes over teh intarwebz? Hacker.
"Security researcher"? Hacker.
Script kiddie? Hacker.
Do fishy things while there's a computer tangentially involded somehow? Hacker.
Place keyboard logger (physical)? Hacker.
Do fishy things while there's a computer in the next room? Hacker. Obviously.
Where the word once indicated someone with great original skill, and in general ment moby technological creativity, requiring your respected fellows to give it to you, it now has become an epithet as easy as the FBI's "mail fraud" indictment: You get'em for free with whatever else you do. Notably "talk to a journalist", or even "be in the vague vicinity of a journalist hack's next piece".
That the term nevertheless got used in criminal legislation is telling of its devolution by overuse. And of legislators a bit too keen to not be seen as hopelessly behind the times.
APT is the latest way of this "IT security industry" full of "hackers" to show that they're down with the cyber, baby. Where "cyber" now-a-days is the clueless' way of saying intarwebbertoobz when they don't want to sound like complete hicks, or just sound officious, notably governments.
So I say the whole bunch of "hackers" is very cyber these days. Cyberhackers with their cyberwhite cyberhats. Selling us cyberprotection against cyberAPTs.
But hackers, they're not. Which is ironic, since hacking is just about the exact opposite of oversimplification. But then, these people don't do ironic. They're dead serious on selling you their definitions and their protection.
Agh. s/truly/& anonymous/. Thanks for forgetting the important point, self.
I'd prefer cash. Around here, though, it's actively being marginalised, in the name of "security", but it's actually shifting risks to me and costing me privacy and flexibility to boot.
It really doesn't matter who owns your wallet, as long as it's not you it means you're being shafted. And this is why we need truly electronic payment mechanisms, not just online, but in our wallets too.
The problem is that the people who can give you such a thing have a perverse incentive not to. This includes, but is not limited to, google.
FreeBSD and NetBSD have an ABI wrapper feature (aka "linuxulator" when wrapping linux) that let you translate syscalls for older versions of the same OS, or even different unixoid OSes. Add userland libraries from the original environment, and you can run the original app unchanged. As long as the application doesn't try and access hard-to-duplicate features, talk to hardware directly, that sort of thing. This gets you a modern and virtualisable OS that can run your old programs.
If there isn't a suitable ABI wrapper for your platform now, at least it could be added relatively easily. Possibly a long shot but at least it's an option to look into.
Virtualisation is great, but there are a few things that cause horrible chicken/egg problems if you virtualise them.
So I'd reserve at least two separate boxes to "do infrastructure". DNS, NTP, remote logging, trap receiving, bastion, and so on. You simply plunk a unix on them and put the individual services in jails or the local equivalent. Don't even need much in the way of performance, so any old 1U box will do fine. Heck, a soekris or an alix board will do. Those are short enough that you can stick'em in any old wiring closet too. Great for geographically dispersing.
If you're stumping up for infrastructure that can host hundreds of VMs, then of course that is enough capacity to also run "little boxes", but it'd be stupid to not also shell out the little extra to make your infrastructure robust, instead of risking hypervisor dependencies on not-yet booted VMs in your private cloud, or whatever you'd call it. "Seems to work" is not enough: Turn off the entire datacentre and then try and cold boot it, remotely. If it's fully virtualised including necessary basic supports, it'll take more time and trouble than if you don't virtualise the pillars on which you built up the rest.
If all I had was exactly two boxes, I'd still run NTP and local DNS next to the hypervisor, not under a guest. NTP in particular; I've had my fill of (windows) boxes claiming to be stratum two yet being off by two minutes because they only update once a week. Of course, on a virtualised unix it'll be much less, but I don't want to find out the hard way the VM distorted the timekeeping in unexpected ways later, so this is one thing that needs its own box. There are similar scenarios for the other basics, but I'll leave them as an exercise. The gains of virtualising, saving a bit on hardware and power, simply do not outweigh the trouble when you can least afford it.
Sorry to have to disappoint you there.
I'm looking for a new desktop, and I found I had to re-assess my shortlist when I realised that the usual single core benchmarks not merely are equally cherry picked, but also are factory rigged in hard-to-compare ways. Notice that the balanced MP cherry picking is your contribution; I just said to not focus on single-core benchmarks only as there's 4 or 8 cores available. My requirements mean that MP is not unimportant, but sheer gaming prowess is.
What with the price, you ask? Perception. intel is sitting pretty so they can (and have) put prices at very neatly balanced gouching points whereas AMD has had a thorough trouncing in the press so they have to provide more perceived value this time round. The bulldozer failure may or may not have been alleviated with thread affinity mods in the OS, but even if they'd fix that now, the damage has been done. Point is: It doesn't need to be an engineering fail to require fixing through pricing drops.
Also note that AMD does drop prices over time, and intel pretty much hasn't for a while. intel can get away with keeping the prices up even with newer and presumably better parts appearing at the same marketing and pricing slots, AMD cannot. That's not all engineering, that's intel sitting pretty and AMD threading water.
Your argument doesn't stack up.
First you say they're bringing an 8 core chip to compete with a 4 core chip. Fine. Then you complain the cores cannot keep up 1:1. So you're expecting AMD's chips to be twice as good as intel's to be able to compete.
That, of course, is rigging the test, and so is dishonest.
One could also say that with single cores not much worse than the competition, but double the number of cores, and a lower price to boot, you get better value. Moreso if you can make good use of the double number of cores.
And that's before considering that single-core benchmarks are entirely unrepresentative for multi-core performance thanks to various tricks like turbo core and turbo boost — that aren't 1:1 comparable so you'd have to do full, sustained benchmarks on all cores simultaneously to find out which delivers the most sustained instructions per second.
Meaning that AMD's offering takes more marketing footwork, but technically is not all bad. Not at all.
The freedom to act must include the freedom to fuck up. (Though it does not imply immunity from consequences.)
So it depends highly on just what consequences you're proposing to attach to "detected pre-crime". If all you do is to "just happen" to appear on the scene, and in case of private property ask people to leave, then you can.
If you are proposing to impose sanctions on not-yet-commited "crimes", or even "merely" build tracking databases, then that means you've reduced freedom some more, in fact you've stooped to thought police. It means that the country in which this is deployed is no longer free.
Does it not? I think that's terribly naïve for a regular reader here, in fact for anyone with an internet connection.
Plus, there is the issue that such systems do effect changes in behaviour; you're effectively making people the string puppets of the technology. I think that's putting the cart before the horse, so this is a class of things we simply really ought not want. In fact, we ought to not want these things.
Having worked on a project done in XML (XML-in-SOAP actually, for double the XML, without specifying where and how to switch to quoted-xml-in-xml input), sort-of, by people who obviously had no fscking clue about specifying anything, much less interop standards, I'm pretty sure that fixed-field ascii would've been a massive improvement over that steaming pile of crap.
There are very definite requirements to specifying interop formats, and the things XML imposes are almost completely orthogonal, making it not a solution for the problem it's supposed to solve.
What you need is people who understand what interoperability entails and how to specify it, in any format. Those are very rare, and none of them are at the W3C. Just read their specifications: They're incredibly one-sided, written entirely for the "website author", and not for the browser writer. No wonder no two browsers act entirely the same on identical input.
There's a big secret that most spec writers fail to grasp, but I'll let you in on it here: For a computer interop format to be of any use, you need both an encoder and a decoder. So, provide reference encoders and decoders along with the spec, so people can check their implementations.
Ideally also provide faulty input so that it may be rejected. For an even more advanced approach there are model checkers that take a state machine representing your protocol and tell you where it'll break down.
But fail to do even the most basic reference designing, and you get something that may never parse. As was the case with above "SOAP" project. XML actually seems to have worsened the interop hell, as well as made processing and storage requirements worse. So, on balance, it's snake oil.
I think it's time to review the provisions of the process. Of course, it's a valid argument that doing it all entirely by hand is a bit much work, the internet being rather large and all that. On the other hand, fully-automated "processing" yields too many false positives, and the rights-holders don't care because they want to avoid false negatives more, nevermind the damage it does to other people's trust in the DMCA, even in copyright.
So we need to give them an incentive to make them care. In the meantime, I'd propose to require all notices to be double-checked by hand. That is, you can use bots all you want, but someone must eyeball the requests before they're issued, at the very least. That, or simply no longer listen to any requests when, not if, some botted party generates too many "oi! that's not yours to take down!" complaints about their "take this down" complaints.
I think there should be a mechanism that loses you your rights to enforce the copyrights you're holding if you're abusing the enforcement mechanism, like by generating too many false positives, yes. "Running a bot that goes amok" counts as abusing. Three strikes, anyone?
There's also the multi-million deals that are made on the back on an envelope... or a beer mat.
Those tend to be the better deals.
As always, in business and in programming and most everywhere else, you really should only introduce complexity when absolutely necessary. excel is a deceptive tool in that regard, it puts a "simple" face on a large bag of unstructured complexity, and then goes about guessing about what it deigns your inputs should actually mean.
Of course, insisting on bespoke software just to "fix" the flaws in excel without understanding the domain or the problem the existing jumble "solves" is a guarantee for getting less done, because the thing is made opaque and inflexible.
But that doesn't mean excel was a good idea in the first place. At best you get poor, shoddy hacks out of it. Despite everything it does right in the eyes of the user. That last bit is important, sure. But it's also important that the solution not fall over at the first sign of trouble, that it gives you a real handle on the complexity and the problem, and for things that aren't one-offs (recall that "temporary" solutions generally outlive "permanent" ones) that the thing scales a bit, not just in size but also in time. As in, it doesn't fall over in obscure ways with the next, or the next, or the next version of the software. And ideally you'd be independent of a single vendor. All things for developers to figure out, I'm sure.
As well they should, because there's a reason excel is seen "inescapable", whether it would still be after a rigorous investigation or not. Well, not just one reason, but it's become ingrained, a habit, the go-to-tool. Even though most who know what computers can do agree that it's not a very good tool at all. It's just so... warm and fuzzy in the minds of the business and enterprise warm body. So. Let's get to it.