Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment Re:Seriously? (Score 1) 522

It's a simple supply and demand problem. It would be like running out of handicapped spaces, and you're pissed about the idiots who bought handicapped equipped vans.

Umm, no. Unlike buying an EV, being handicapped isn't really a choice.

When the fix is so simple, and can be monetized, and app driven as well, the amount of Slashsillieness applied is a bit funny.

Agreed. Wanna charge up? get out your credit card. Otherwise learn to plan your route accordingly.

Comment Re:Hipsters fight over limited supplies of juice (Score 4, Informative) 522

Dunno... up here in Portland, I've lost count of the prime parking 'chargers only 'cuz we're teh environmentalz!!!!' spots that sit empty most of the time, even during peak shopping/working hours.

Wouldn't mind having the EV owners pay for the privilege, though, because if they don't, the rest of us do (the stores aren't installing the things out of the goodness of their hearts, you know, and they have to recoup the costs somewhere).

Comment Re:Who? (Score 1) 688

1) I don't care what RMS does with his toenails... it's his code and writing that I care about.

2) Who ever said that Torvalds "never does wrong"? Dude's not perfect, but he's managed to keep the kernel going strong this far. By comparison, what have you done?

Comment Re:Who? (Score 3, Interesting) 688

Given the downmods each of us got in the pile, it seems this is a contentious issue.

Personally, I disagree with your assessment, but that said, I am aware that one person's fair assessment followed by a harsher and unequivocal reply if the assessment is rejected, may easily be seen by another as undue abuse.

I make no apologies for the list, because it reminds me exactly of a typical USAF flightline. Doing something dumb or misguided will get you a direct and to-the-point talking-to; first logical and fair, but increasingly harsher if you continue to resist even listening.

The reasons why are different but just as serious: in the kernel, screw-ups in design and/or direction can eventually destroy the kernel's usefulness and flexibility. On the flightline, screwups in procedure or behavior will eventually get you killed.

The harshness against any whining and/or backtalk in either case is not just someone being a turd - it's a reminder that there are reasons for things being as they are, and any proposed changes had better have a damned good reason up-front.

HTH a little.

Comment Re:PT Barnum (Score 1) 174

Agreed. The only machine-type game that has any kind of consistent hope is playing odd/even on a roulette wheel with a single "0", which gives you a 48.6% (or so) chance of winning (a "00" on the wheel drops your chances to to 47.4%). Any other game that uses a machine will only get worse from there.

At least with single-deck poker (and no card-counters) you have some sort of chance... but only if you know what you're doing and are more skilled than your opponents.

Comment Re:Outsider (Score 1) 174

Actually, since the information they have is essentially the same, it's more like a slot machine tech working at one casino making slot bets at another. There's still a chance that the guy will lose, but his odds are way better than most, especially if he knows of certain bugs in certain machines and can leverage them.

It's a big reason why folks like the Nevada Gaming Commission demand that technicians not gamble at all (IIRC, it came in the wake of a technician exploiting a bug by way of a palmed magnet back in the 1990s(?) or so.)

Comment Re:Who? (Score 5, Insightful) 688

Although this project will probably never end up being used in any wide way, shouldn't the Linux community be concerned that it's running talent away with a poor culture?


Anyone with any real experience in hacking the Linux kernel already knows what they're getting into. It is also very widely known that Linus is incredibly fair in his assessments. If you provide useful contributions, no worries. If your commit is a total brainfart, you'll get a rejection, but the abuse won't come unless you decide to be a dumbass or get all arrogant about it.

It's about as fair as it gets.

Comment Re:Not a hard and fast rule... (Score 2) 281

If there is one BS that needs to be called, it is the one on the "collaborative open plan office". Which would be slightly off-topic, and all but beaten to death.

You can never beat that ill-begotten bullshit idea to death. In fact, it needs to not only die, but have its corpse beaten until each subatomic particle is separated from the other, then have the whole mess carefully scattered to the four winds.

Comment Re:Not a hard and fast rule... (Score 1) 281

Since when does a DevOp develop a micro service?

I was thinking about that... you can, to an extent, guide a team (a decent company will give you that ability and authority). OTOH, you'd have to get into the whole politics thing with the architects, team leads, and product owners before you could push anything like this.

That said (and as TFA says), not all projects in a company are suited for it.

Something else comes to mind... sometimes it does more harm than good to bust up a monolith. I know of a project that was broken down this way, and it wound up doing astoundingly stupid things (e.g. spewing 4,500 IPC calls betwixt 5 different servers just to establish one user session). While they really should have refactored the whole thing first (trust me, it's an ancient legacy stack that deserves to be re-written), they instead shot for breaking the thing down into bite-sized chunks, with little thought towards architecture or even communication between groups.

Comment Re:MMM is not about technology (Score 1) 281

And in fact, the fundamental problems are not technology-based, but organizational/political ones. I love microservices, but they are, in the great scheme of things, a technical detail. No amount of technical silver bullet will help subvert organizational/political forces.

This, a million times this...

I did note however that TFA was aimed squarely at the C-level types (CIO/CTO) - these folks would be in the best position to do something about the politics, fiefdoms, etc and etc. The typical developer, sysadmin or devops guy? Not so much. Folks at our level only get to watch.

(On the other hand, it's good to keep an eye on the trends anyway, if only to divine which fad-of-the-month that you will most likely be afflicted with in the near future...)

Comment Re:Not a hard and fast rule... (Score 2) 281

Let me be clear: there are a class of problems that cannot be solved just by working more energetically.

Actually, TFA specifically says you'll most likely have to re-architect the product/application/problem *first*, before you just throw energy at it. TFA also goes on to say that you have to fundamentally change the structure of your organization if it isn't suited to the task (e.g. siloed orgs, etc).

No where in TFA does it say you have to simply throw more resources at the problem.

In fact, it even goes so far as to say that not all problems/projects are adaptable to this:

One thing CIOs need to understand is that you don’t just buy a can of “Microservices” and paint all your code with it and be done. How you get there depends on whether you are trying to alter an existing monolithic application or are designing from scratch. Author Martin Fowler says most successful microservices start with an existing app and re-architect it and that it’s much harder to design for microservices from scratch.

Lastly, microservices are not a boon to everyone. On-premise software, for example, might not be right for microservices, given the amount of coordination and infrastructure that is needed to deploy microservices applications. That doesn’t mean on-premise software couldn’t be architected around a set of services, but the deployment scenario (e.g. ship as a single-war or as an installer) precludes deploying as such.

Comment I am curious about one thing... (Score 1) 66

...what was the business case for writing a library set for some very limited conditions?

I mean, yeah, I guess it would be kind of cool to run Windows x86 binaries on certain models of smartphone and all, but honestly, under what conditions did they think this would be useful (beyond the obvious 'gee whiz' factor)?

Mind, I'm not normally one to go reaching for business justifications and such, but I can't shake the feeling that they did this to, well, stay relevant. These days, if there's an application that I really need that only runs on Windows, I either find a workaround, or fire up a VM (viz. VirtualBox) and do whatever it is I needed to do with that application.

There was once a time where something like this was IMHO desperately needed (I'm talking long ago, back when Win4Lin was a thing), but nowadays? I just don't see it...

Comment Re:reLOCATES the heatsink and fans (Score 1) 45

True indeed... but then, you can pipe it off to a heatsink sitting off to the side (meaning you can make the overall device thinner), and the closer proximity betwixt fluid and heat source means that you don't need as large of a heatsink (mostly because you're not waiting for a relatively large amount of heat to work its way out past the packaging.)

The trouble with doing something right the first time is that nobody appreciates how difficult it was.