I quite like the idea of a Senate Launch System.
I hope it launches in the direction of the Sun.
I quite like the idea of a Senate Launch System.
I hope it launches in the direction of the Sun.
Nice dodging and weaving, but I'm guessing you know the point will find you in the end.
It's called critical mass. Once enough people cease to believe in your funny green rectangle, it's finished as a carrier of value. Greed has nothing to do with it because greed only applies to things with value. However, the point (which you seem to accept implicitly while denying it) is that the belief makes the money.
As for the shaman, he just slips something in your drink so you later die horribly. Then everyone naturally believes you were strong, but the shaman was stronger still and resistance just made it worse. He needn't explain that, they'll make the story up themselves. If he somehow fails that, don't worry, you'll die after everyone shuns you so the cures doesn't get on them. Then they'll "remember" that you died promptly just like the myth says.
I mean, a lot of code is only meant for one platform type. Not writing code compatible with obsolete processors is no great sin.
Fair enough. Ideally, you should include a generic version without any hackish optimizations, but it isn't strictly required if you don't think you'll ever change CPUs in the future. Either way, if you're writing code that you know is likely to break on a different architecture because of its unique characteristics, IMO, you should at least make it fail to build on any other architecture than the ones you've tested....
We've all got grandparents or great grandparents who fought in something so you can cut off your cross for a start.
Well they'll be able to empathize with the situation. It is unlikely that you have ever written to a politician after reading a legislation like this to defend the remaining democracy. I have, so perhaps the best thing you can do is move to north korea or some other military dictatorship to cheer them on, or just STFU and let the rest of us spend our time ensuring the rule of law applies to all in democracies. After all, that is the point of a democracy.
What a mature reaction on your part, GTFU.
The exact same "police state" rhetoric arguments was wheeled out when fingerprinting was indroduced, then DNA matching, then CCTV.
Yes, and step by step it incrementally becomes more of a police state until someone steps in, uses those powers and it becomes a dictatorship. Perhaps you are an optimist who trusts leaders to implicitly do the right thing. We've seen you before, you pick on the weak and oppressed while defending the powerful and corrupt, who think of you as a rather useful idiot.
Change the bloody record.
I'd love to but people like you keep pressing repeat. I know the soundtrack. We've seen the movie so many times, the film is flapping on the side of the projector, the reel is over, the end is always the same, and at the beginning are people like you who allow power structures like this to evolve and dictators to exist. You are the domestic enemy we are warned about.
The song is always the same because you just aren't comfortable with any other tunes.
To put it another way you enjoy being anally fist fucked, so to make you feel normal, you want everyone to experience it if only they would just stop fighting and give in. After that, you don't know because you don't think that far ahead.
I wouldn't be surprised to see far worse things come down the pipe, especially malware that exploited domain admin rights to compromise the entire AD forest.
However, we have one big defense against all of this: Virtualization. Not just VM farms, but VDI (so a compromised desktop can just be rolled back to a known good snapshot almost instantly.) If the malware can't touch hardware, it can still destroy/corrupt files, but VMs have a lot more tools available for mitigating/reversing such attacks, even if it is just a simple snapshot of files taken daily which persists a week before expiring. Of course, snapshots are not backups, but they are a tool to help with RTO/RPO.
Another defense is separation. The AD domain used for authenticating to the NetBackup server, SAN, and tape drive is completely separate than the AD forest used for day to day user work. This way, a domain or enterprise admin account that gets compromised on a user's desktop cannot be used to destroy all data on a silo, SAN, or NAS. It will still be pure hell rebuilding the AD structure if malware does use it as a propagation vector, but at least the core appliances won't be affected.
Of course, the final defense are good backup and archival policies. For example, a backup is done daily, and is kept 7-14 days. Another backup is done weekly, kept 4-8 weeks. A monthly backup is fired off, kept 12-24 months, and a quarterly backup is kept 7-20 years on WORM media. Of course, offsite and verification policies go without saying as well. It also doesn't hurt to run a hash of stored files and cryptographically sign that on an offline machine, just as a last resort for detecting tampering.
I have a feeling we will not just see more destructive attacks, but more subtle ones. A simple change in a purchase order can bankrupt a company. So, because this actually hurts businesses (as opposed to the previous "copy data and leave everything alone" intrusions of the past), we might see actual money spent for handling data integrity as part of enterprise security.
Is that as evil as you can get? You can kill people with this, from a long distance. Just make a worm, take ransom in bitcoins. You should be able to amass a tidy sum in the few days it takes to get every pump in the country disconnected and replaced.
Depends. Is it wrapped with #if __i386__ || __x86_64__ and followed by a #else clause that contains code without the insane optimization? If so, it is elegant. If not, it is ugly.
To recognize that a line of code is an ugly hack, someone would have to first understand it, and as we all know, only Perl can parse Perl.
C developers are good enough to know when what they're doing is an ugly hack.
If PHP developers were at the same standard, every line would end with
// Ugly Hack.
I think the reason PHP is #2 on the list is that the people who are still writing PHP are mostly pretty good. The ones who were awful have all moved on to Python or Ruby or whatever the scripting language of the week is these days.
In fact, I'd be willing to bet that a sizable percentage of the folks who are still actively using PHP are C programmers. I use it for all my web programming because it is exceptionally easy for me as a long-time C programmer. I basically write C with dollar signs and a few other minor tweaks, and it works. Even better, if there's some piece of code that has to be blisteringly fast, I can port it from PHP to C faster than you can say sed 's/\$//sg'. Okay, it really isn't quite that trivial, but it is pretty close.
And yes, I do occasionally take advantage of being able to mix PHP and HTML, but not very often. I mostly just use it as a compile-free web programming language with better string handling and basic support for classes.
C Code EVERYWHERE has the most "ugly hacks"
C code is ugly hacks. But how else are you going to write an efficient ring buffer?
You could at least try to read the entire summary.
Your notion of "optimizing for the hardware" is something that isn't real. According to your theory, Linux also shouldn't perform well because it also is hardware-agnostic.
As for what OEMs have to do, a modern mobile device is immensely complex, consisting of dozens of processors, many on the SoC (system on a chip) but many not. All of them have to be configured, which is a complex and tedious operation, and easy to get wrong -- and every custom board requires a custom configuration. In addition, there are drivers for all of the bits and pieces that have to be assembled and tested together. Plus there's also typically a complex, multi-stage boot process that has to be orchestrated to bring up all the bits and pieces of the hardware in the right way and in the right order. And other stuff that I don't know about because I'm not a hardware systems guy.
Some of the above doesn't depend on the OS, and can be done before it's available. But much of it does depend on OS requirements and has to wait.
And then if the OEM decides to customize Android they have to do that, with whatever skin, and default apps they want, plus whatever changes they need deep in the system to support the hardware and their changes to the software. Finally there is lots and lots of testing, because such complex, custom devices always expose new interactions between components that have to be debugged and fixed. Oh, and lots of hardware testing as well, including endless burn-in tests to validate that the stuff not only works but that some subtle design flaw doesn't stop it from working.
And I'm sure there's still more that I don't know about at that level as well.
Then they have to run Google's compliance tests, to find out what they've broken with all of their changes, or what they missed in configuring their device for proper support (actually, this is something they do throughout, not at the end), and then go back and fix what's broken until it passes... or else negotiate with Google for waivers on things they think should be okay.
Then comes carrier validation and testing, more rounds of fixes, etc.
Little or none of this has anything to do with "optimization". That's mostly the compiler's job, and it does that job well.
Sure, but by which point you're doing much more involved forensics and hunting this down.
In many companies, a misbehaving computer is just re-imaged.
We used to have a receptionist who put so much crap on her PC that every couple of months when she decided she'd broken it enough, they'd just re-image it.
Why nobody ever told her to stop putting that crap on in the first place I'll never understand.
In that kind of scenario, nobody would even know she had any specific malware or what it did.
If I set here and stare at nothing long enough, people might think I'm an engineer working on something. -- S.R. McElroy