Follow Slashdot stories on Twitter


Forgot your password?

Comment Wrong question. (Score 1) 40 40

These 'zOMG, everyone should STEM up and become an app entrepreneur!!!' stories aren't really about the desirability of everyone having a career in software development. They are more a reflection of the fact that plucky optimists looking for what kids should do to be successful when they grow up are...not exactly...swimming in options. Yes, they are also letting the fascination with shiny trendy things distort their perception of the options, hence the fascination with who will make the next Social Twitfriend app, rather than who will write unbelievably dull line of business stuff; but in broader strokes they aren't pushing this because it's a good idea, they are pushing it because it's an idea, and they don't have another one.

The pronouncement that 'software is eating the world' may have been a bit hyperbolic; but it sure isn't doing the life chances of people without advanced qualifications any favors. "Everyone writing apps" sounds slightly better than "Everyone selling each other securitized bullshit", so it gets more face time.

Comment Re:/|\ Double degree economics & English. At D (Score 2) 131 131

No, I'm saying companies are cheap and don't tend to make a lot of variations on models because it costs them more, unless they think it's worth it.

If they figure only 5-10% of the market would buy a phone with a physical keyboard, they might not be willing to chase that because it's not worth it. And if it poses a risk to make something until they know how many would be sold, they just might not do it.

Just because you want a feature doesn't mean the company making it gives a damn. If they did, they'd probably make it.

Comment Re:what a moron (Score 1) 385 385

Read: he should point out our faults then just let us take whatever revenge we feel like.

Or more likely, hide what he has to say, tell him he'll go to prison for the rest of his life if he tells, and then do absolutely nothing differently.

So, he had the choice, be silenced and live in fear in the US ... or not be silenced and live in fear somewhere else.

But there is no way in hell if he'd brought these concerns though "proper channels" a damned thing would changed.

They just got embarrassed when the truth came out. They only really care about the fact that people found out, not what they did.

There is no way he could have achieved a damned thing by doing anything other than release this stuff.

She is a total moron. How do such people ever get such responsible jobs?

The scary thing is there's lots of people willing to be fascists because they think it's OK. The justification is "I can do anything as long as I say I'm doing it to defend my country", even if they're undermining everything worth defending about their country.

The sad thing is, apparently a lot of Americans would agree, and believe security at any cost is an OK thing.

Comment Re:unless you need it wait... (Score 1) 121 121

Oh, don't misunderstand me ... I know people do need this stuff when it's fresh and steaming, and have no choice.

I'm saying that, in general, as a change management strategy, taking the first day release of a fix has been demonstrated to be a terrible idea. Over and over and over by pretty much every software vendor.

Many of us support production machines and mission critical things, which means there's no way in hell we'd apply these on the day they get released.

What really annoys me is Microsoft's increasing push to force people to take those updates on day one, and be stuck with the consequences of that.

So, imagine a world in which some poor schmuck is running the version of Windows 10 which doesn't let you defer updates. When Microsoft pushes this crap out, suddenly a huge amount of people have broken systems. Microsoft isn't going to pay to fix that. Microsoft isn't going to have to deal with the consequences of the outage.

So, the general advice of "if you don't absolutely need this on the day of release, wait" is the best strategy if you can't be on the bleeding edge every day Microsoft has a new fix.

Microsoft seems bent on taking that away. And that, in my opinion, is idiotic and dangerous.

If you need to be on the cutting edge, you should probably be taking your own steps to recover from that. Mine is let everyone else test first. ;-)

Comment Re:No Compromises (Score 1) 131 131

Well, honestly, given that people make bluetooth keyboard cases this is fairly trivially solved if you care enough.

Maybe phone companies figure the accessories market can solve this problem?

I'm willing to bet it's a smaller amount of people who want a physical keyboard than those who don't. In which case, you're not a profitable enough segment for the companies who make phones, but an excellent niche market for people who make accessories.

It's not like you can't have what you want now, you just won't get it from the main companies selling phones.

Comment Re:unless you need it wait... (Score 1) 121 121

There's a massive difference between knowing there are likely bugs in your software and believing that the day a fix or patch comes out it doesn't introduce new issues.

Microsoft, and pretty much every other software vendor I've ever seen have demonstrated time and time again that they're incapable of releasing updates without breaking something else.

So, we let the reckless and the silly be the beta testers, and wait until the dust settles. And, that's fine, because we can simply choose to wait to apply the fix for a while.

Microsoft wants to go to a "break first and fix it later" approach, and that's just asinine. Because it isn't their computers which will be broken in the meantime.

Sometimes you just have to ship the product.

Sure you do. But don't be surprised that your users refuse to be your beta testers and wait for more people to do that. Your QA is your problem, and I have no intention of making it mine.

The people who go "oh, boy, a brand new update" provide the valuable service to the rest of us of being test subjects. And they can live with the consequences.

The rest of us, well, after the first bunch of times we've learned our lesson.

So, be my guest. Run through the fresh steaming shit with reckless abandon. But I won't. Because I've seen Microsoft updates be broken upon release quite a few times, as I have from pretty much every other vendor.

Comment Re:Change Is Life (Score 1, Insightful) 121 121

You know, if Microsoft changes the library in place and breaks it ... I don't blame professional developers at all.

I blame whatever idiot at Microsoft was responsible for not fucking breaking existing stuff.

This is just lousy QA.

I feel bad for anybody who is going to be the victim of Micrtosoft's idiotic policy of deciding it's their computer and they'll update it as they see fit. Because it is a certainty Microsoft will break a large amount of computers and leave that to be the problem of the people who own it.

And, I'm sorry, but if Microsoft is going to force updates and break machines, they should be charged under the computer fraud and abuse act, or whatever it is.

Because this is pretty much damaging other people's property, and shouldn't be legal just because some asshole at Microsoft updated an EULA which says they're allowed to do this.

Comment Re:unless you need it wait... (Score 1) 121 121

So to your point, taking a .0 release from any vendor is risky but if you have to have it, you have to have it and learn to deal with the consequences.

Why, yes, I even said that

My experience says taking a day 1 anything from Microsoft is a recipe for disaster. In fact, taking a day 1 from anybody is.

I don't care who you are, I simply do not trust your fresh release of anything, I do not wish to fix your mistakes, and do not believe over time you'll be awesome at not breaking anything ever. In fact, I think that's impossible to do 100% of the time.

Not now, not ever. Because many many years of doing change management has told me that would be stupid and reckless, and I don't work in places which are willing to do that.

Unfortunately, Microsoft seems to be trying to go down the route of pretty much forcing as many people as possible to get the updates immediately.

Either because they're arrogant morons, or they figure it's just easier if everybody else does their beta testing.

There isn't a software vendor on the planet I would accept a first day release from. And I've seen far too many day 1 mistakes from Microsoft and other vendors to ever change that.

Comment Re:Who cares? (Score 5, Interesting) 121 121

Why is the story of Slashdot being sold not on SLASHDOT!?!?!?

Well, ignoring the rest of your comment, this is actually worth highlighting.

The Company acquired Slashdot Media in 2012 both to provide the Dice business with broader reach into Slashdot's user community base and to extend the Dice business outside North America by engaging with SourceForge's significant international technology user community. The Company, however, has not successfully leveraged the Slashdot user base to further Dice's digital recruitment business; and with the acquisition of The IT Job Board and success of Open Web, the anticipated value to the Company of the SourceForge traffic outside North America has not materialized. The Company now plans to divest the business, as it does not fit within the Company's strategic initiatives and believes the Slashdot Media business will have the opportunity to improve its financial performance under different ownership.

Good riddance, dice.

Sorry we couldn't help you leverage your synergies.

Actually, we're not sorry at all.

Comment Re:Correct link to TRA (Score 1) 94 94

An alarming number of those hold for Chromium and they all stem from one core issue: Google developers do not understand how to design APIs. A lot of the bundled projects could be entirely separate repositories and shipped as shared libraries if they did, but gratuitous API churn means that they have to keep copies of things like v8 and Skia for Chrome and build the whole thing at once. It's fine to do the aggregate build thing if you want LTO, but it should be a performance optimisation, not a requirement of the software engineering workflow.

Comment Re:unless you need it wait... (Score 2) 121 121

Which is the problem with Microsoft trying to force people to use it, and deciding they're going to be forcing updates.

They're saying they're doing it for security, but time and time again Microsoft has demonstrated they're not trustworthy in their updates.

My experience says taking a day 1 anything from Microsoft is a recipe for disaster. In fact, taking a day 1 from anybody is.

Microsoft is basically breaking first and fixing later. The problem is it isn't Microsoft's stuff which ends up broken, and bad release engineering is costly to companies.

Sorry, but Microsoft hasn't demonstrated we should ever trust them with continuous releases. They've demonstrated the opposite, in fact.

Comment Re:I disagree with some of these points (Score 2) 94 94

It depends a lot on the codebase. Codebases tend to accumulate cruft. Having people refactor them because their requirements are different to yours can help, as can having a project developed without key product ship dates as the driving force. The bigger barrier is culture though. It's really hard to have a group of developers that have been working on a project for 10 years in private move to developing in public. In the list, he actually gives different numbers of fail points, more for projects that were proprietary for longer than they were open, which makes a lot more sense than the summary in the 'article'.

The one that I disagree with is 'Your source builds using something that isn't GNU Make [ +10 points of FAIL ]'. I disagree for two reasons. The first is that it implies using GNU make features, which likely means that you're conflating building and build configuration (which should gain some fail points). The projects that I most enjoy hacking on use CMake and Ninja for building by default (CMake can also emit POSIX Makefiles that GNU Make can use, but I take his point to mean that gmake is the only command you need to build, so the CMake dependency would be a problem). LLVM still more or less maintains two build systems, though the autoconf + gmake one is slowly being removed in favour of the CMake one. If I make a small change, it takes Ninja less time to rebuild it than it takes gmake to work out that it has nothing to do if I don't make any changes.

I'd also disagree with 'Your code doesn't have a changelog' - this is a GNU requirement, but one that dates back to before CVS was widely deployed. The revision control logs now fill the same requirement, though you should have something documenting large user-visible changes.

A programming language is low level when its programs require attention to the irrelevant.