I'm not sure it was simply rude behavior during a call. I think it had more to do with the fact that he used privileged contact information from work to "escalate" his own customer service problem, started name dropping, and then threatened Comcast with accounting ethics / oversight boards. From that perspective, it's not surprising he was fired. It was an incredibly inappropriate thing to do, as he might have caused serious harm to his employer's business relationship with Comcast.
We don't really know that's what's happened, but that's my guess from reading between the lines. As horrible a company as Comcast may be, it doesn't make sense for them to contact his employer unless he actually made what they considered to be credible threats against them - and the article actually says that's just what he did:
During this call, he says that he mentioned that Comcast’s billing and accounting issues should probably be investigated by the Public Company Accounting Oversight Board (PCAOB), a private-sector oversight operation.
Combined with the *implied* name dropping, and the fact that he knew who to call higher up in the corporate food chain, Comcast might well take it at face value that he's in a very real position to make this happen, and reacted to that by contacting his employer to make sure this wasn't actually going to happen. The accounting company reacted in a way entirely predictable when they found one of their employees was abusing confidential contact information in order to threaten one of their clients with an ethics investigation. I know it's cool to hate on Comcast and big business here, but this guy may actually have been in the wrong, even if Comcast was in the process of providing him with their usual shit service and runarounds.
Oh, and this doesn't let Comcast off the hook for their mistakes and poor service with this guy either. A story about such poor customer service should be news on its own merits. But just because Comcast was wrong doesn't necessarily make what this guy did any more right.
This is pretty typical of modern corporate America, unfortunately. Wall Street often rewards layoffs with a stock price bump, because it's an easy way to cut costs and boost short-term profits, as well as a way for a company to rid itself of any potential deadwood (in theory) that's dragging it's performance down. It's pretty likely this is also a move that will generate a short term boost as well, which means high-fives all around the boardroom.
Well, it would be foolish to get sentimental over the withering of a corporation, except for the fact that the low folks on the totem pole are the ones who get laid off first. Business tends to be Darwinian in nature, and if HP can't get it's shit together, then it simply leaves room for a competitor that will, and hopeful those new competitors are hiring. It's aggravating that CEOs continue to profit while they suck the life from a business, but I suppose it's quite literally none of my business how they want to run and ruin theirs.
"Having a pair" and firing without positively identifying targets means accidentally shooting down airliners on occasion, and no one wants that. It's a tough spot for our armed forces, no doubt, and I don't think it's helpful to oversimplify the problem. Robot boats are essentially disposable, so they're a great way to allow the Navy to get in close for better identification before enemies get close enough to kill our sailors, as well as warn off anyone who is just curious or happens to stray into the wrong area.
We actually have a lot of less-than-lethal technologies at our disposal now as well. Employing those as a first defense in peacetime seems pretty reasonable to me. Why risk accidental death with our abundance of highly lethal weapons if we don't have to? If intruders keep coming past the obvious warnings and attacks by heat beams or sonic weapons, then by all means, break out the big guns and allow our personnel to properly protect themselves.
I'm actually glad to see the Navy thinking outside the box instead of simply building more giant carriers. These smaller boats are probably pretty inexpensive, comparatively speaking, and seem much more suited for the sort of asymmetric warfare they're likely to face in the future.
Asking for the state of an industry from people who leave that industry seems pretty likely to get you negatively biased results. If you asked *men* who left the industry, you'd probably hear about a lot of negative experiences other than sexism, but still just as negative. I'm not saying it's not a problem, but just pointing out that there may be a selection bias here. It would have been interesting to compare and contrast the views of those who left and those who remained to see if the perceptions were similar.
While female programmers are rare in the videogame industry as well, they're not unheard of. I think the situation there is probably a bit healthier (on the development side, at least), because there are lots of female artists, designers, QA, management, etc, to help balance things out. In general, I've worked at about half a dozen game companies, and they all seemed fairly female-friendly to me. At least, the women that worked there seemed happy enough, and didn't seem like the type to put up with any nonsense in the first place.
Incidentally, the audio department seems to be another place staffed almost exclusively with men. For some reason, there are extremely few sound designers or composers, rather similar to programming. Not sure why that is...
Good judgment in choosing language features to use is a far lower bar than never making programming mistakes that accidentally stomp all over memory you don't own or leak resources in some corner case.
There are plenty of languages that are arguable "better" than C or C++, but part of C's strength at this point is it's universal / ubiquitous nature. It's literally *everywhere* - the first thing anyone does with a new chip is to make or modify a C compiler to support it. Part of C++'s (admittedly pragmatic) appeal is that you don't have to throw out your entire codebase to start using it, since it's largely backwards-compatible with C. Any suggestions to throw out all legacy code and start fresh with a new language ends up being a completely academic exercise.
A lot of people consider C compatibility a weakness of C++. From a pure design standpoint, sure. From an actual pragmatic, we-need-to-use-this-in-the-real-world standpoint, it's a huge advantage, not a disadvantage, because of the massive amount of C code actually being used in real-world products.
Unfortunately, you can't use any of that in the kernel [overloading create/destroy new/delete operators won't cut it]. Spinlocks, rwlocks, RCU, slab allocation, per cpu variables, explicit cache flush, memory fence operations, I/O device mappings, ISRs, tasklets, kmalloc vs vmalloc, deadlocks, livelocks, etc. are the issues a kernel programmer has to deal with. Nothing in C++ will help with these and some C++ constructs are actually a hindrance rather than a help.
For instance, copy constructors must be disabled. This was part of a proposal a few years back to make a C++ subset suitable for realtime/embedded.
Surely not every line of code in a kernel has to deal with *all* of that, right? C++ allows you to gracefully fall back to lower level abstractions where you need to and use the higher level abstractions where necessary. The fact that portions of the kernel are apparently currently being rewritten in C++ suggests that it's not impossible to do so. Copy constructors, assignment operators, and other overloads are trivially disabled in your own classes, of course. I don't think anyone would sanely suggest that a kernel starts pulling in all parts of the STL library or anything like that. Nor would anyone with sense suggest that code start blindly calling generic 'new' and 'delete' to allocate objects. Hell, in my own codebase (a game / custom engine), every single allocation goes to a custom allocator instead of new. C++ makes possible to do this just like C does.
Even beyond that, what percentage of a kernel would you suspect is so touchy / critical that C++ wouldn't be appropriate for it? I'm taking a wild-ass guess, but I'd be shocked if anyone told me it was greater than 10-20%, with the other 80-90% being more mundane and less-oft executed but still necessary code. I'd imagine C++ could probably be used there to simplify and make safer normal operations in those areas. Maybe people more familiar with the Linux kernel code would have a better idea than my guess.
Even in my own code, for instance, in my custom memory allocator, of course I'm using C-style structs, raw pointers, and all sorts of dangerous, low-level pointer tricks and casts. There are some circumstances that absolutely require that type of low-level code. The point, though, is that you really only have to use that dangerous, low-level code where absolutely necessary, and everywhere else you can use safer abstractions.
The only thing C++ solves in kernel development are problems that nobody cares about. Replacing macros with templates and long function names with namespaces buys the kernel developers precisely nothing.
Replacing macros with templates and long functions names aren't exactly the killer benefits most people think about for C++. It's typically things like avoiding memory corruption and resource leaks, which can both be really bad in an OS kernel. Even so, I'd argue that they DO buy kernel developers something. Macros are completely type unsafe, and can silently generate bugs. More sanely named overloaded functions and namespaces help to make code more readable. Are kernel developers somehow magically exempt from features the rest of the world finds useful?
Still, even as a C++ advocate, I would never really argue that C++ solves all problems, is easier to use, has no hidden costs, or even is the correct language to use in all situations. Good C++ programmers understand the costs of features they are using and the tradeoffs they're making. There are bad programmers in every language, including C++. Personally, I'll probably always choose C++ for my own projects that require high-performance native code because it provides some very significant benefits:
1) Using class based abstractions can virtually eliminate some really dangerous categories of bugs like buffer overruns. 2) It's almost impossible to leak memory or resources with properly designed wrapper/interface classes. 3) Well written C++ interfaces can make it harder to misuse APIs in general 4) These benefits are typically provided at either zero or with minimal overhead. There is no "hidden" overhead if you understand how the language feature or library works. 5) For times that this overhead is critical, you can revert back to C. For all other cases, you can prefer the higher-level abstractions and the safety and convenience they provide.
Generally speaking, I'd say it's harder to write good C++ code and design great C++ interfaces. However, once those interfaces are created, they tend to be far easier and safer to use - even for the person who originally wrote them. Most of my own library classes are designed in such a way that I couldn't cause crashes, leaks, or memory corruptions with them unless I tried really hard to do so using blatantly unsafe techniques (which C++ lets you do, of course, just like with C).
If I had to sum up, the significant benefit of C++ is that it makes it possible to protect the programmer from making mistakes to a much greater degree than in C while retaining most of the performance benefits of C. We've seen it demonstrated quite clearly, time after time after time... programmers are only human, and will always make silly mistakes. Why not take advantage of the language and compiler to help minimize the chances of making those mistakes in the first place? To me, that's the essence of C++.
Fortunately, all the latest versions of the major browsers no longer make it so easy to install third party crap silently. If people are using duff browsers, as you put it, then there's really nothing to be done for them. It's not like anyone charges money for a modern browser, and even the latest versions of Chrome and Firefox are still available for Windows XP service pack 2.
I agree that it's hard to blame users for the sleazy tricks some companies use to install this crap, which is why I think there's an argument to be made that most people are actually better off in a well-tended walled garden (sad to say). Installations that do things like that should never get let past the gates. MS has recently realized this, which is why they started cleaning their app store a bit. Unless people can trust what's in the store more than what they get out in the wild, there's zero point to using an "official" app store.
Moreover, I think the media needs to do more in calling out companies that engage this sort of behavior. The negative PR from doing so needs to outweigh the financial advantages of getting in bed with sleazy companies like Ask.com and their horrid toolbar. At least, that would be the ideal, but it doesn't seem to be happening. These sorts of tactics are really hurting the PC platform by making it unbelievably treacherous for ordinary users to manage their own computers. It's no wonder people are switching in droves to smartphones or tablets as their "primary" computing platforms. At least it's not quite as easy (although not impossible, of course) for a single rogue app to compromise your entire system.
I hear the "C++ is doing things behind my back" argument all the time, but that pretty much goes against every recommended practice out there. Most programming experts recommend against hiding complex operations behind "hidden" methods (and that's not unique to C++ either). If you call an overloaded operator and it's doing a bunch of crazy things behind your back that you didn't expect, it's a very poor interface, and not necessarily the fault of the language. In fact, C++ gives you a lot of tools to help you know what's going on behind the scenes of a member function, for example. If a function is declared const, you know that it's not affecting the internal state of an object. Likewise, if you're passing in a const reference, you know it can't be modified inside the function. Also, C++ 11, with better support for r-value semantics (think temporary variables), has eliminated a lot of hidden constructor/destructor costs when objects are moved around.
I think it's perfectly fine to use C with classes if that's what suits you personally or the task at hand. The entire point of C++ and it's compatibility with C is that you can use as much or as little of the higher-level abstractions as you need. Simply wrapping a resource inside an object is enormously powerful all on it's own, because it's nearly impossible to then leak that resource or use it improperly since you're protecting access to it, and using the compiler to enforce that proper access.
C++ programmers do tend to be their own worst enemies at times, endlessly looking for clever language tricks to massively over-complicate their code when a simpler if slightly less elegant approach would end up being about 10x easier to read, understand, and maintain in the long run. I'm actually not a huge advocate of using new language features until it's absolutely clear that it makes the code simpler and more maintainable in the long run. Take for instance C++ lambda functions. They're enormously handy for passing first-class member functions as callbacks, say, to a UI system. Any C++ programmer can look at the following code and see exactly what it does (despite the rather ugly syntax):
Even for non C++ programmers, it's probably not hard to guess that this is simply providing an OnClickOk() member function callback to a button (this comes straight from my game code). There's no magic there. The compiler is implicitly creating a small object that stores the object's 'this' pointer, and invokes it's member function on demand. C++ (and C) famously adhere to the zero overhead principle - that is, you don't pay for features you aren't using. In this case, the optimized result of storing and invoking a pointer is exactly the same as if you had passed in a function pointer in the traditional C style, only this is much safer AND more readable.
C++ certainly is a more difficult language to master than C, but I definitely think the payoff, in terms of code safety and maintainability versus performance, is certainly well worth the investment.
C++ is an enormously powerful and comprehensive language, and it relies on the programmer or organization to use a reasonable subset of it and use good judgement in applying any given feature. I would grant that poorly written C++ is probably much worse to detangle than poorly written C. However, well written C++ is just as usable and maintainable as well written C. More critically, C++ interfaces and methods can be written in such a manner as to provide much better protection to the programmer from his own mistakes. It's much harder to do that in C. In today's security-conscious world, where a single mistake can mean a critical OS vunerability, that's a real issue.
Essentially, C++ is C plus the ability to create powerful abstractions, typically expressed in objects/classes and templates, but not necessarily limited to those. Those abstractions put more of a burden on the compiler rather than the programmer, and as a result, is much safer than anything one could write by hand. All raw memory buffer manipulation, for instance, can be done through carefully protected wrapper objects or other user-defined primitives, and there's no reason in modern C++ to manipulate object lifetime through raw pointers, as it now has standardized smart pointers. Any resource - memory, file, locks, handle, etc, should be lifetime managed by objects - and so modern C++ should feel a lot like a garbage-collected language. In fact, I'd say it's superior to a garbage collected language in many respects, because garbage collection is not nearly as predictable as object scope rules, and doesn't extend quite as nicely to non-memory resource management (e.g. IDisposable in C#).
It's certainly not a language suitable for all tasks, and it arguably requires more expertise than C to use it well. However, systems programming is absolutely one of those things it's well suited for. Binary compatibility would be great to have, but is not a real hurdle. To work around it, you can simply fall back to a C-like API at module boundaries, and avoid passing any objects across. That's what I typically do when I have to write C# C++ interop layers, and it's worked pretty well for me. While it brings along a lot of cruft, C compatibility, including it's binary compatibility, is one of C++'s great strengths as a language.
I agree. It's definitely hard to avoid, and it's a huge problem on Windows. Even installing software from "reputable" companies can get you into trouble. A lot of companies make shady deals to promote various products (like the Ask toolbar installing with Java). I installed a new HP printer, and was prompted to install a shit-load of various 3rd party applications, NONE of which were necessary to get the device to print, but does who-knows-what to your system. There was no option I could discern for installing the more "necessary" bits separately (like functionality for controlling higher-level printer functions, such as cleaning the heads), so I just ended up using the default (and completely functional) basic driver available in Windows. I actually have to pull out my printer heads and clean them manually from time to time, though, which is sort of sad.
While it's true users do install a lot of sketchy stuff, it's hard to blame people for everything that can go wrong. In fairness, even when legitimate companies are doing this, it's really hard for the average user to know they need to be wary until they get bitten a few times. Over the years, I've had to become hypersensitive about installing software just to keep my system crapware free. It's sad when you can't even trust the discs you get with new hardware purchases.
The US Constitution was founded on the principle that you do, in fact, have inherent rights. "Inalienable" is the phrase used, and it's been described elsewhere as "natural rights". Whether or not a judge or the state protects those rights have no bearing on whether those rights exist for an individual. The most important thing in our society is a general understanding of these principles, because our only real protection is a general societal agreement that these rights need to be protected and defended.
In practice, unfortunately, I agree that it's little consolation to one who's rights are defined them. But I still think it's a distinction worth making. If everyone gives up and says it's hopeless, then the battle is certainly lost. As it is, it's still an ongoing struggle. Human nature being what it is, it's *always* going to be a struggle, and so we can't ever afford to give up the fight.
I'd posit that, as a general rule of thumb, many conservatives tend to distrust the government except for the military and law-enforcement / national security agencies. It was Reagan who quipped that the nine most terrifying words were "I'm from the government and I'm here to help." Many liberals seem to have the opposite view, mostly trusting the government (or supporting a bigger role for the government in many cases, at least) except for military, security, and law enforcement.
Other than that, the big difference is in how much rage is directed at the head-of-state. There's obviously more of a tendency to directly blame the guy in charge if you're of an opposing political ideology. For those of the same ideology, you'll hear stuff about blaming "the government", "the bureaucracy" / agency in question, or the individual announcing the policy - Holder in the case.
In this particular case, I was actually surprised to see the title specifically call this out as the "Obama Administration" rather than using a more politically-neutral term. So, there are always exceptions to any generalization or rules of thumb.
I used to have to do a clean install of Windows every few years to keep things performing well, but I don't recall doing that since the switch to NT-based systems (starting with 2000 for me personally). For users that keep installing malware/adware/spyware on their systems, it seems entirely likely that they'd have to do a clean re-install to get rid of all the cruft every once in a while. Some of that stuff is pretty hard to remove, and can really cause issues with system stability and performance.
When people talk about "OS decay", they're probably dealing with systems that have either a huge amount of software churn, a lot of crapware, or very often both. It's not so much about "learning how to use Windows 7" so much as not installing free, sketchy utilities that contain system-hogging spyware. Or perhaps it's better termed "learning not to abuse your operating system". People do the same sort of nonsense with their phones - install dozens of apps that all want do stay resident for whatever reason, and then they wonder where the battery life went. Same deal - if you give people the freedom to customize their device, some people will inevitably make bad choices.
I don't know if this applies to you parents or not, but I've certainly seen plenty of cringe-inducing systems for people to know just enough to be dangerous. My parent don't know enough to really do anything of consequence on their computer other than check e-mail, surf the net, and play solitaire, so their system (Windows XP) has stayed nice and tidy for the last seven or eight years (I think) they've had that machine.
My family owns a business in light manufacturing. When one of the workers gets a new tool set, they literally throw away the metric tools, because they're completely worthless in typical industrial use. Multiply that imperial-unit inertia by about a million small hardware-related businesses and manufacturers across the country, and you can see why no one has been eager to swallow the cost of that conversion.
I agree with you about the tooling and infrastructure issue. Go to a local home depot and check out the selection of nuts, bolts, washers, screws, pins, connectors, etc. Most of those are still in imperial units. Some people "pooh, pooh" the actual cost of a real, complete conversion from one unit system to another. Most of those people tend to neglect the actual hardware in use today, and how pervasive those units are throughout the entire US manufacturing base. It would literally cost billions of dollars in conversion costs, and in the end, all we'll end up with is a more "mathematically pure" measurement system - zero functional difference. To local businesses and firms, there is literally no benefit to the conversion in the short term - only cost. The government would literally have to mandate a change by law to kickstart this, and it would be a short-term but real hit on the US economy.
It would be great if the US could switch to metrics. Most people - educated ones at least - understand it's a saner system and is better both for internal consumption and for international interoperability. But it's not what we have, and no one currently believes the conversion is actually worth the price we'd pay. It's one of the prices the US pays for having such a large, isolated infrastructure. It's harder for us to adapt to changes in some ways because of our sheer size, and there's much less pressure externally than with smaller, individual markets. The cultural resistance is not insignificant either, but that could be overcome with time.
Probably the best way to make it happen is for the government to provide some tax benefits to companies willing to do the conversion, and allow the transition to occur a bit more naturally over time. That would help to disguise the cost (there's no free lunch there, though), and eliminate some of the grumbling, and as such, some of the political opposition. It's not enough to just label things in different but equivalent units. Until you make the internal conversions in the low-level infrastructure, all you're doing is creating more work by superficially labeling things less efficiently.
Degrees is also a generic term used for incremental measurement, as in "degrees of freedom". Just because something is measured in degrees doesn't mean it should be related to circular measurements of any sort. At least, I can't see the point in it.
Why are you blaming the doctors, lawyers, and bureaucrats? There's no way to universally extract data from these proprietary systems and transmit it via e-mail to someone else, and certainly not securely. It's obviously a kludge, and everyone is starting to recognize this, which is why it's generating headlines - that's a start. Fax machines will die as soon as there's no actual use for them. We're obviously not at that point yet, so it's a good thing we have these older systems in place. The current headlines are far preferable to "Doctors are unable to exchange medical records with colleagues".
Scanning and e-mailing a document is semantically *exactly the same* as faxing it, only it's likely harder for the average office worker to do. What's the point of that? The solution is to create actual digital interoperability, not simply to arbitrarily remove the *one* solution that is actually solving the current problem, however clumsily.
You say "we've never managed more than season colonies" on Antarctica, which is a little unfair, since we've never *tried* to do anything other than that. There's no good reason to build a large colony in Antarctica, and as such, it's neither been proposed nor attempted.
If you're suggesting this as an alternative solution, you forget that the entire point is to create an "offsite backup" for humanity. If it's for a technological litmus test of some sort, I don't see the point, because as you point out, there are huge differences between the two environments.
Honestly, just focus on the goal of making it self-sustaining from an industrial and technological standpoint - that's the hard part. Humanity will expand by itself and naturally create plenty of genetic backup genes. Expanding our population has never been one of our problem areas.
MS - ditch the clown paint and hire some designers that can create an appealing interface.
It won't work. From what I can tell, the entire designer community is currently convinced that gradients, transparency, and actual buttons or menus you can see / distinguish are the devil, and everything should be either some completely flat shade of white on white, or else some hideous primary color that makes your eyes bleed.
Everywhere I look, I see formerly attractive interfaces turning flat and ugly. I was really hoping Windows 9... er 10 wouldn't keep the same horrible-looking theme, but it looks like they're sticking with it for now.
It actually crossed my mind, but man, would that be lame if it were true. A curved backplate designed for strength is patentable? Every structural engineer on the planet learns this in his first year statics course (or probably in high school). I hope to high hell it isn't patented, even though I like my HTC One, because I'd just have to cry. Prior art includes soda and beer cans.
A quick search turned up no obvious hits, but I certainly could have missed it. Every time I searched, I got a lot of hits for Apple's patents on curved rectangles and curved batteries, etc.
I'm a game developer, and they're claiming their engine to be suitable for game development, so I'm just evaluating it on that basis. If it works well in other domains, good for them, but I know nothing about those industries. However, game engines have a lot of *very specific* requirements in order to make them practical. At the moment, generating game assets by 3D scanning objects is simply a non-starter for all but a very specific set of games.
Polygonal-based tools and pipelines are deeply entrenched in the industry right now, and I suspect anyone who cuts against the grain is going to make it pretty hard on themselves for a very minimal visual payoff. That tends to happens to pioneering technologies, even if they later become mainstream. Just my opinion, obviously, because we haven't seen anything more than static renderings so far.
I was recently pondering whether my game engine (written in C++) should have it's native OSX back-end / interop written in Swift or Objective-C. From what I can see, for what I need to do, Objective-C remains the clear choice, at least for now. There's a lot of good documentation on Objective-C / Cocoa, as well as lots of examples for how to interop between Objective-C and C++. I haven't even been able to determine if this is possible with Swift after searching around a bit on the net. Interop with Objective-C, yes, but that's pointless for me. I don't see Apple obsoleting or depreciating Objective-C in the near future. There's a heck of a lot of legacy code in that language, and like you mentioned, it seems like Swift wouldn't even be a proper replacement at this point for everything Objective-C can currently do.
As with pretty much any other language-choice debate, you really first need to know what someone plans to do with it before you can make a worthwhile recommendation. All languages have strengths and weaknesses, so it's foolish to point to one without even knowing what you'll be doing. The OP first wants to know about "quick and easy" for which I'd probably recommend Swift, but then wants "portability", for which I'd recommend C (for him, since he knows that - personally I use C++) with carefully walled off interfaces to the GUI frontend, but *only* if the complexity merits such treatment rather than a simple port in native code for each version. Without any more info, I can't make a better recommendation than that really.
Also, make sure there there's a safe way to remove the headset without killing the player due to a high-powered radiation burst, which a brilliant but psychotic game developer has devised in order to trap players inside his revolutionary virtual online game world until they can track him down and defeat him, thus allowing everyone to finally escape and re-join the real world.
This company with it's impressive-looking but completely static scenes shows up every few years. Honestly, I didn't see anything that couldn't be done in that video with any modern engine targeting high-end video hardware. It's a bit of a cheat if you only have to show the terrain. I'll be more impressed when I see a demo with physics, animation, and dynamic lighting, because that's where things tend to get tricky. They mentioned in the video that they do have animation working - I'll be curious to see how it looks in the next video.
This company seems to be trying to solve the problem of how to accurately capture and reproduce the real world, but how many games actually want to capture real-world data? If you're in the business of creating fantasy worlds of any sort - and that's precisely what most games are - there's nothing in the real world for you to scan. There's a reason no one else is working this way, I think. As far as the game industry goes, I'm guessing it will probably remain a very niche product, if it's viable at all. I just don't see them throwing away 15 year's worth of maturing polygon-based tools and technologies anytime soon.
Slashdot Mirror
I'm not sure it was simply rude behavior during a call. I think it had more to do with the fact that he used privileged contact information from work to "escalate" his own customer service problem, started name dropping, and then threatened Comcast with accounting ethics / oversight boards. From that perspective, it's not surprising he was fired. It was an incredibly inappropriate thing to do, as he might have caused serious harm to his employer's business relationship with Comcast.
We don't really know that's what's happened, but that's my guess from reading between the lines. As horrible a company as Comcast may be, it doesn't make sense for them to contact his employer unless he actually made what they considered to be credible threats against them - and the article actually says that's just what he did:
During this call, he says that he mentioned that Comcast’s billing and accounting issues should probably be investigated by the Public Company Accounting Oversight Board (PCAOB), a private-sector oversight operation.
Combined with the *implied* name dropping, and the fact that he knew who to call higher up in the corporate food chain, Comcast might well take it at face value that he's in a very real position to make this happen, and reacted to that by contacting his employer to make sure this wasn't actually going to happen. The accounting company reacted in a way entirely predictable when they found one of their employees was abusing confidential contact information in order to threaten one of their clients with an ethics investigation. I know it's cool to hate on Comcast and big business here, but this guy may actually have been in the wrong, even if Comcast was in the process of providing him with their usual shit service and runarounds.
Oh, and this doesn't let Comcast off the hook for their mistakes and poor service with this guy either. A story about such poor customer service should be news on its own merits. But just because Comcast was wrong doesn't necessarily make what this guy did any more right.
This is pretty typical of modern corporate America, unfortunately. Wall Street often rewards layoffs with a stock price bump, because it's an easy way to cut costs and boost short-term profits, as well as a way for a company to rid itself of any potential deadwood (in theory) that's dragging it's performance down. It's pretty likely this is also a move that will generate a short term boost as well, which means high-fives all around the boardroom.
Well, it would be foolish to get sentimental over the withering of a corporation, except for the fact that the low folks on the totem pole are the ones who get laid off first. Business tends to be Darwinian in nature, and if HP can't get it's shit together, then it simply leaves room for a competitor that will, and hopeful those new competitors are hiring. It's aggravating that CEOs continue to profit while they suck the life from a business, but I suppose it's quite literally none of my business how they want to run and ruin theirs.
"Having a pair" and firing without positively identifying targets means accidentally shooting down airliners on occasion, and no one wants that. It's a tough spot for our armed forces, no doubt, and I don't think it's helpful to oversimplify the problem. Robot boats are essentially disposable, so they're a great way to allow the Navy to get in close for better identification before enemies get close enough to kill our sailors, as well as warn off anyone who is just curious or happens to stray into the wrong area.
We actually have a lot of less-than-lethal technologies at our disposal now as well. Employing those as a first defense in peacetime seems pretty reasonable to me. Why risk accidental death with our abundance of highly lethal weapons if we don't have to? If intruders keep coming past the obvious warnings and attacks by heat beams or sonic weapons, then by all means, break out the big guns and allow our personnel to properly protect themselves.
I'm actually glad to see the Navy thinking outside the box instead of simply building more giant carriers. These smaller boats are probably pretty inexpensive, comparatively speaking, and seem much more suited for the sort of asymmetric warfare they're likely to face in the future.
Asking for the state of an industry from people who leave that industry seems pretty likely to get you negatively biased results. If you asked *men* who left the industry, you'd probably hear about a lot of negative experiences other than sexism, but still just as negative. I'm not saying it's not a problem, but just pointing out that there may be a selection bias here. It would have been interesting to compare and contrast the views of those who left and those who remained to see if the perceptions were similar.
While female programmers are rare in the videogame industry as well, they're not unheard of. I think the situation there is probably a bit healthier (on the development side, at least), because there are lots of female artists, designers, QA, management, etc, to help balance things out. In general, I've worked at about half a dozen game companies, and they all seemed fairly female-friendly to me. At least, the women that worked there seemed happy enough, and didn't seem like the type to put up with any nonsense in the first place.
Incidentally, the audio department seems to be another place staffed almost exclusively with men. For some reason, there are extremely few sound designers or composers, rather similar to programming. Not sure why that is...
Good judgment in choosing language features to use is a far lower bar than never making programming mistakes that accidentally stomp all over memory you don't own or leak resources in some corner case.
There are plenty of languages that are arguable "better" than C or C++, but part of C's strength at this point is it's universal / ubiquitous nature. It's literally *everywhere* - the first thing anyone does with a new chip is to make or modify a C compiler to support it. Part of C++'s (admittedly pragmatic) appeal is that you don't have to throw out your entire codebase to start using it, since it's largely backwards-compatible with C. Any suggestions to throw out all legacy code and start fresh with a new language ends up being a completely academic exercise.
A lot of people consider C compatibility a weakness of C++. From a pure design standpoint, sure. From an actual pragmatic, we-need-to-use-this-in-the-real-world standpoint, it's a huge advantage, not a disadvantage, because of the massive amount of C code actually being used in real-world products.
Unfortunately, you can't use any of that in the kernel [overloading create/destroy new/delete operators won't cut it]. Spinlocks, rwlocks, RCU, slab allocation, per cpu variables, explicit cache flush, memory fence operations, I/O device mappings, ISRs, tasklets, kmalloc vs vmalloc, deadlocks, livelocks, etc. are the issues a kernel programmer has to deal with. Nothing in C++ will help with these and some C++ constructs are actually a hindrance rather than a help.
For instance, copy constructors must be disabled. This was part of a proposal a few years back to make a C++ subset suitable for realtime/embedded.
Surely not every line of code in a kernel has to deal with *all* of that, right? C++ allows you to gracefully fall back to lower level abstractions where you need to and use the higher level abstractions where necessary. The fact that portions of the kernel are apparently currently being rewritten in C++ suggests that it's not impossible to do so. Copy constructors, assignment operators, and other overloads are trivially disabled in your own classes, of course. I don't think anyone would sanely suggest that a kernel starts pulling in all parts of the STL library or anything like that. Nor would anyone with sense suggest that code start blindly calling generic 'new' and 'delete' to allocate objects. Hell, in my own codebase (a game / custom engine), every single allocation goes to a custom allocator instead of new. C++ makes possible to do this just like C does.
Even beyond that, what percentage of a kernel would you suspect is so touchy / critical that C++ wouldn't be appropriate for it? I'm taking a wild-ass guess, but I'd be shocked if anyone told me it was greater than 10-20%, with the other 80-90% being more mundane and less-oft executed but still necessary code. I'd imagine C++ could probably be used there to simplify and make safer normal operations in those areas. Maybe people more familiar with the Linux kernel code would have a better idea than my guess.
Even in my own code, for instance, in my custom memory allocator, of course I'm using C-style structs, raw pointers, and all sorts of dangerous, low-level pointer tricks and casts. There are some circumstances that absolutely require that type of low-level code. The point, though, is that you really only have to use that dangerous, low-level code where absolutely necessary, and everywhere else you can use safer abstractions.
The only thing C++ solves in kernel development are problems that nobody cares about. Replacing macros with templates and long function names with namespaces buys the kernel developers precisely nothing.
Replacing macros with templates and long functions names aren't exactly the killer benefits most people think about for C++. It's typically things like avoiding memory corruption and resource leaks, which can both be really bad in an OS kernel. Even so, I'd argue that they DO buy kernel developers something. Macros are completely type unsafe, and can silently generate bugs. More sanely named overloaded functions and namespaces help to make code more readable. Are kernel developers somehow magically exempt from features the rest of the world finds useful?
Still, even as a C++ advocate, I would never really argue that C++ solves all problems, is easier to use, has no hidden costs, or even is the correct language to use in all situations. Good C++ programmers understand the costs of features they are using and the tradeoffs they're making. There are bad programmers in every language, including C++. Personally, I'll probably always choose C++ for my own projects that require high-performance native code because it provides some very significant benefits:
1) Using class based abstractions can virtually eliminate some really dangerous categories of bugs like buffer overruns.
2) It's almost impossible to leak memory or resources with properly designed wrapper/interface classes.
3) Well written C++ interfaces can make it harder to misuse APIs in general
4) These benefits are typically provided at either zero or with minimal overhead. There is no "hidden" overhead if you understand how the language feature or library works.
5) For times that this overhead is critical, you can revert back to C. For all other cases, you can prefer the higher-level abstractions and the safety and convenience they provide.
Generally speaking, I'd say it's harder to write good C++ code and design great C++ interfaces. However, once those interfaces are created, they tend to be far easier and safer to use - even for the person who originally wrote them. Most of my own library classes are designed in such a way that I couldn't cause crashes, leaks, or memory corruptions with them unless I tried really hard to do so using blatantly unsafe techniques (which C++ lets you do, of course, just like with C).
If I had to sum up, the significant benefit of C++ is that it makes it possible to protect the programmer from making mistakes to a much greater degree than in C while retaining most of the performance benefits of C. We've seen it demonstrated quite clearly, time after time after time... programmers are only human, and will always make silly mistakes. Why not take advantage of the language and compiler to help minimize the chances of making those mistakes in the first place? To me, that's the essence of C++.
Fortunately, all the latest versions of the major browsers no longer make it so easy to install third party crap silently. If people are using duff browsers, as you put it, then there's really nothing to be done for them. It's not like anyone charges money for a modern browser, and even the latest versions of Chrome and Firefox are still available for Windows XP service pack 2.
I agree that it's hard to blame users for the sleazy tricks some companies use to install this crap, which is why I think there's an argument to be made that most people are actually better off in a well-tended walled garden (sad to say). Installations that do things like that should never get let past the gates. MS has recently realized this, which is why they started cleaning their app store a bit. Unless people can trust what's in the store more than what they get out in the wild, there's zero point to using an "official" app store.
Moreover, I think the media needs to do more in calling out companies that engage this sort of behavior. The negative PR from doing so needs to outweigh the financial advantages of getting in bed with sleazy companies like Ask.com and their horrid toolbar. At least, that would be the ideal, but it doesn't seem to be happening. These sorts of tactics are really hurting the PC platform by making it unbelievably treacherous for ordinary users to manage their own computers. It's no wonder people are switching in droves to smartphones or tablets as their "primary" computing platforms. At least it's not quite as easy (although not impossible, of course) for a single rogue app to compromise your entire system.
I hear the "C++ is doing things behind my back" argument all the time, but that pretty much goes against every recommended practice out there. Most programming experts recommend against hiding complex operations behind "hidden" methods (and that's not unique to C++ either). If you call an overloaded operator and it's doing a bunch of crazy things behind your back that you didn't expect, it's a very poor interface, and not necessarily the fault of the language. In fact, C++ gives you a lot of tools to help you know what's going on behind the scenes of a member function, for example. If a function is declared const, you know that it's not affecting the internal state of an object. Likewise, if you're passing in a const reference, you know it can't be modified inside the function. Also, C++ 11, with better support for r-value semantics (think temporary variables), has eliminated a lot of hidden constructor/destructor costs when objects are moved around.
I think it's perfectly fine to use C with classes if that's what suits you personally or the task at hand. The entire point of C++ and it's compatibility with C is that you can use as much or as little of the higher-level abstractions as you need. Simply wrapping a resource inside an object is enormously powerful all on it's own, because it's nearly impossible to then leak that resource or use it improperly since you're protecting access to it, and using the compiler to enforce that proper access.
C++ programmers do tend to be their own worst enemies at times, endlessly looking for clever language tricks to massively over-complicate their code when a simpler if slightly less elegant approach would end up being about 10x easier to read, understand, and maintain in the long run. I'm actually not a huge advocate of using new language features until it's absolutely clear that it makes the code simpler and more maintainable in the long run. Take for instance C++ lambda functions. They're enormously handy for passing first-class member functions as callbacks, say, to a UI system. Any C++ programmer can look at the following code and see exactly what it does (despite the rather ugly syntax):
okButtonParams.clickEvent = [this]() { this->OnClickOK(); };
Even for non C++ programmers, it's probably not hard to guess that this is simply providing an OnClickOk() member function callback to a button (this comes straight from my game code). There's no magic there. The compiler is implicitly creating a small object that stores the object's 'this' pointer, and invokes it's member function on demand. C++ (and C) famously adhere to the zero overhead principle - that is, you don't pay for features you aren't using. In this case, the optimized result of storing and invoking a pointer is exactly the same as if you had passed in a function pointer in the traditional C style, only this is much safer AND more readable.
C++ certainly is a more difficult language to master than C, but I definitely think the payoff, in terms of code safety and maintainability versus performance, is certainly well worth the investment.
C++ is an enormously powerful and comprehensive language, and it relies on the programmer or organization to use a reasonable subset of it and use good judgement in applying any given feature. I would grant that poorly written C++ is probably much worse to detangle than poorly written C. However, well written C++ is just as usable and maintainable as well written C. More critically, C++ interfaces and methods can be written in such a manner as to provide much better protection to the programmer from his own mistakes. It's much harder to do that in C. In today's security-conscious world, where a single mistake can mean a critical OS vunerability, that's a real issue.
Essentially, C++ is C plus the ability to create powerful abstractions, typically expressed in objects/classes and templates, but not necessarily limited to those. Those abstractions put more of a burden on the compiler rather than the programmer, and as a result, is much safer than anything one could write by hand. All raw memory buffer manipulation, for instance, can be done through carefully protected wrapper objects or other user-defined primitives, and there's no reason in modern C++ to manipulate object lifetime through raw pointers, as it now has standardized smart pointers. Any resource - memory, file, locks, handle, etc, should be lifetime managed by objects - and so modern C++ should feel a lot like a garbage-collected language. In fact, I'd say it's superior to a garbage collected language in many respects, because garbage collection is not nearly as predictable as object scope rules, and doesn't extend quite as nicely to non-memory resource management (e.g. IDisposable in C#).
It's certainly not a language suitable for all tasks, and it arguably requires more expertise than C to use it well. However, systems programming is absolutely one of those things it's well suited for. Binary compatibility would be great to have, but is not a real hurdle. To work around it, you can simply fall back to a C-like API at module boundaries, and avoid passing any objects across. That's what I typically do when I have to write C# C++ interop layers, and it's worked pretty well for me. While it brings along a lot of cruft, C compatibility, including it's binary compatibility, is one of C++'s great strengths as a language.
I agree. It's definitely hard to avoid, and it's a huge problem on Windows. Even installing software from "reputable" companies can get you into trouble. A lot of companies make shady deals to promote various products (like the Ask toolbar installing with Java). I installed a new HP printer, and was prompted to install a shit-load of various 3rd party applications, NONE of which were necessary to get the device to print, but does who-knows-what to your system. There was no option I could discern for installing the more "necessary" bits separately (like functionality for controlling higher-level printer functions, such as cleaning the heads), so I just ended up using the default (and completely functional) basic driver available in Windows. I actually have to pull out my printer heads and clean them manually from time to time, though, which is sort of sad.
While it's true users do install a lot of sketchy stuff, it's hard to blame people for everything that can go wrong. In fairness, even when legitimate companies are doing this, it's really hard for the average user to know they need to be wary until they get bitten a few times. Over the years, I've had to become hypersensitive about installing software just to keep my system crapware free. It's sad when you can't even trust the discs you get with new hardware purchases.
The US Constitution was founded on the principle that you do, in fact, have inherent rights. "Inalienable" is the phrase used, and it's been described elsewhere as "natural rights". Whether or not a judge or the state protects those rights have no bearing on whether those rights exist for an individual. The most important thing in our society is a general understanding of these principles, because our only real protection is a general societal agreement that these rights need to be protected and defended.
In practice, unfortunately, I agree that it's little consolation to one who's rights are defined them. But I still think it's a distinction worth making. If everyone gives up and says it's hopeless, then the battle is certainly lost. As it is, it's still an ongoing struggle. Human nature being what it is, it's *always* going to be a struggle, and so we can't ever afford to give up the fight.
I'd posit that, as a general rule of thumb, many conservatives tend to distrust the government except for the military and law-enforcement / national security agencies. It was Reagan who quipped that the nine most terrifying words were "I'm from the government and I'm here to help." Many liberals seem to have the opposite view, mostly trusting the government (or supporting a bigger role for the government in many cases, at least) except for military, security, and law enforcement.
Other than that, the big difference is in how much rage is directed at the head-of-state. There's obviously more of a tendency to directly blame the guy in charge if you're of an opposing political ideology. For those of the same ideology, you'll hear stuff about blaming "the government", "the bureaucracy" / agency in question, or the individual announcing the policy - Holder in the case.
In this particular case, I was actually surprised to see the title specifically call this out as the "Obama Administration" rather than using a more politically-neutral term. So, there are always exceptions to any generalization or rules of thumb.
I used to have to do a clean install of Windows every few years to keep things performing well, but I don't recall doing that since the switch to NT-based systems (starting with 2000 for me personally). For users that keep installing malware/adware/spyware on their systems, it seems entirely likely that they'd have to do a clean re-install to get rid of all the cruft every once in a while. Some of that stuff is pretty hard to remove, and can really cause issues with system stability and performance.
When people talk about "OS decay", they're probably dealing with systems that have either a huge amount of software churn, a lot of crapware, or very often both. It's not so much about "learning how to use Windows 7" so much as not installing free, sketchy utilities that contain system-hogging spyware. Or perhaps it's better termed "learning not to abuse your operating system". People do the same sort of nonsense with their phones - install dozens of apps that all want do stay resident for whatever reason, and then they wonder where the battery life went. Same deal - if you give people the freedom to customize their device, some people will inevitably make bad choices.
I don't know if this applies to you parents or not, but I've certainly seen plenty of cringe-inducing systems for people to know just enough to be dangerous. My parent don't know enough to really do anything of consequence on their computer other than check e-mail, surf the net, and play solitaire, so their system (Windows XP) has stayed nice and tidy for the last seven or eight years (I think) they've had that machine.
My family owns a business in light manufacturing. When one of the workers gets a new tool set, they literally throw away the metric tools, because they're completely worthless in typical industrial use. Multiply that imperial-unit inertia by about a million small hardware-related businesses and manufacturers across the country, and you can see why no one has been eager to swallow the cost of that conversion.
I agree with you about the tooling and infrastructure issue. Go to a local home depot and check out the selection of nuts, bolts, washers, screws, pins, connectors, etc. Most of those are still in imperial units. Some people "pooh, pooh" the actual cost of a real, complete conversion from one unit system to another. Most of those people tend to neglect the actual hardware in use today, and how pervasive those units are throughout the entire US manufacturing base. It would literally cost billions of dollars in conversion costs, and in the end, all we'll end up with is a more "mathematically pure" measurement system - zero functional difference. To local businesses and firms, there is literally no benefit to the conversion in the short term - only cost. The government would literally have to mandate a change by law to kickstart this, and it would be a short-term but real hit on the US economy.
It would be great if the US could switch to metrics. Most people - educated ones at least - understand it's a saner system and is better both for internal consumption and for international interoperability. But it's not what we have, and no one currently believes the conversion is actually worth the price we'd pay. It's one of the prices the US pays for having such a large, isolated infrastructure. It's harder for us to adapt to changes in some ways because of our sheer size, and there's much less pressure externally than with smaller, individual markets. The cultural resistance is not insignificant either, but that could be overcome with time.
Probably the best way to make it happen is for the government to provide some tax benefits to companies willing to do the conversion, and allow the transition to occur a bit more naturally over time. That would help to disguise the cost (there's no free lunch there, though), and eliminate some of the grumbling, and as such, some of the political opposition. It's not enough to just label things in different but equivalent units. Until you make the internal conversions in the low-level infrastructure, all you're doing is creating more work by superficially labeling things less efficiently.
Degrees is also a generic term used for incremental measurement, as in "degrees of freedom". Just because something is measured in degrees doesn't mean it should be related to circular measurements of any sort. At least, I can't see the point in it.
Why are you blaming the doctors, lawyers, and bureaucrats? There's no way to universally extract data from these proprietary systems and transmit it via e-mail to someone else, and certainly not securely. It's obviously a kludge, and everyone is starting to recognize this, which is why it's generating headlines - that's a start. Fax machines will die as soon as there's no actual use for them. We're obviously not at that point yet, so it's a good thing we have these older systems in place. The current headlines are far preferable to "Doctors are unable to exchange medical records with colleagues".
Scanning and e-mailing a document is semantically *exactly the same* as faxing it, only it's likely harder for the average office worker to do. What's the point of that? The solution is to create actual digital interoperability, not simply to arbitrarily remove the *one* solution that is actually solving the current problem, however clumsily.
You say "we've never managed more than season colonies" on Antarctica, which is a little unfair, since we've never *tried* to do anything other than that. There's no good reason to build a large colony in Antarctica, and as such, it's neither been proposed nor attempted.
If you're suggesting this as an alternative solution, you forget that the entire point is to create an "offsite backup" for humanity. If it's for a technological litmus test of some sort, I don't see the point, because as you point out, there are huge differences between the two environments.
Honestly, just focus on the goal of making it self-sustaining from an industrial and technological standpoint - that's the hard part. Humanity will expand by itself and naturally create plenty of genetic backup genes. Expanding our population has never been one of our problem areas.
MS - ditch the clown paint and hire some designers that can create an appealing interface.
It won't work. From what I can tell, the entire designer community is currently convinced that gradients, transparency, and actual buttons or menus you can see / distinguish are the devil, and everything should be either some completely flat shade of white on white, or else some hideous primary color that makes your eyes bleed.
Everywhere I look, I see formerly attractive interfaces turning flat and ugly. I was really hoping Windows 9... er 10 wouldn't keep the same horrible-looking theme, but it looks like they're sticking with it for now.
It actually crossed my mind, but man, would that be lame if it were true. A curved backplate designed for strength is patentable? Every structural engineer on the planet learns this in his first year statics course (or probably in high school). I hope to high hell it isn't patented, even though I like my HTC One, because I'd just have to cry. Prior art includes soda and beer cans.
A quick search turned up no obvious hits, but I certainly could have missed it. Every time I searched, I got a lot of hits for Apple's patents on curved rectangles and curved batteries, etc.
I'm a game developer, and they're claiming their engine to be suitable for game development, so I'm just evaluating it on that basis. If it works well in other domains, good for them, but I know nothing about those industries. However, game engines have a lot of *very specific* requirements in order to make them practical. At the moment, generating game assets by 3D scanning objects is simply a non-starter for all but a very specific set of games.
Polygonal-based tools and pipelines are deeply entrenched in the industry right now, and I suspect anyone who cuts against the grain is going to make it pretty hard on themselves for a very minimal visual payoff. That tends to happens to pioneering technologies, even if they later become mainstream. Just my opinion, obviously, because we haven't seen anything more than static renderings so far.
I was recently pondering whether my game engine (written in C++) should have it's native OSX back-end / interop written in Swift or Objective-C. From what I can see, for what I need to do, Objective-C remains the clear choice, at least for now. There's a lot of good documentation on Objective-C / Cocoa, as well as lots of examples for how to interop between Objective-C and C++. I haven't even been able to determine if this is possible with Swift after searching around a bit on the net. Interop with Objective-C, yes, but that's pointless for me. I don't see Apple obsoleting or depreciating Objective-C in the near future. There's a heck of a lot of legacy code in that language, and like you mentioned, it seems like Swift wouldn't even be a proper replacement at this point for everything Objective-C can currently do.
As with pretty much any other language-choice debate, you really first need to know what someone plans to do with it before you can make a worthwhile recommendation. All languages have strengths and weaknesses, so it's foolish to point to one without even knowing what you'll be doing. The OP first wants to know about "quick and easy" for which I'd probably recommend Swift, but then wants "portability", for which I'd recommend C (for him, since he knows that - personally I use C++) with carefully walled off interfaces to the GUI frontend, but *only* if the complexity merits such treatment rather than a simple port in native code for each version. Without any more info, I can't make a better recommendation than that really.
Also, make sure there there's a safe way to remove the headset without killing the player due to a high-powered radiation burst, which a brilliant but psychotic game developer has devised in order to trap players inside his revolutionary virtual online game world until they can track him down and defeat him, thus allowing everyone to finally escape and re-join the real world.
Or at least, that's what I've learned from anime.
This company with it's impressive-looking but completely static scenes shows up every few years. Honestly, I didn't see anything that couldn't be done in that video with any modern engine targeting high-end video hardware. It's a bit of a cheat if you only have to show the terrain. I'll be more impressed when I see a demo with physics, animation, and dynamic lighting, because that's where things tend to get tricky. They mentioned in the video that they do have animation working - I'll be curious to see how it looks in the next video.
This company seems to be trying to solve the problem of how to accurately capture and reproduce the real world, but how many games actually want to capture real-world data? If you're in the business of creating fantasy worlds of any sort - and that's precisely what most games are - there's nothing in the real world for you to scan. There's a reason no one else is working this way, I think. As far as the game industry goes, I'm guessing it will probably remain a very niche product, if it's viable at all. I just don't see them throwing away 15 year's worth of maturing polygon-based tools and technologies anytime soon.