Become a fan of Slashdot on Facebook


Forgot your password?
Take advantage of Black Friday with 15% off sitewide with coupon code "BLACKFRIDAY" on Slashdot Deals (some exclusions apply)". ×

Comment Re:The takeaway is that Tesla is right (Score 2) 449

Even beyond the conflict of interest, the dealer doesn't actually provide a useful knowledge base to help you make an informed decision when buying a car. If you ask them *any* question whose answer isn't plainly stated on the sticker or in the meager sales brochure, you will get one of two answers: 1) A shrug and, "I dunno". or 2) A flat out lie. A couple hours of research on a car will make you the foremost expert in the building on that particular car. By a significant margin. Car sales people are the quientissential useless middle man. Maybe at one time they served a real purpose but, that time has long passed and now they just basically skim a bit of money off something they didn't create, don't know anything about and really don't even give a shit about.

Comment Re:Duh (Score 2) 699

You make good arguments and if I could, I'd mod you up even though I don't agree with you. One of the reasons that linux has been popular as a server OS is that you could easily distill it down to just the parts you needed. If you didn't like a particular component you could swap it out with a component more to your liking or even write a replacement. From a security standpoint, you were presenting a smaller attack surface by running a small number of heterogeneous components from different sources. From a maintainability standpoint you could easily read and understand the impact that updates might have. Sure, there were kludges and hacks and, if you wanted to argue that X-Windows is the most prolific kludge in the history of computing, I probably wouldn't argue with you.

The small, modular, "do what I want" nature of linux is basically the thing that makes linux, linux. If you wanted an opaque box that included everything but the kitchen sink, you could just use Windows. And that's what people hate about systemd: It's starting a trend to make linux more Windows-like and that is rightfully seen as a horrible direction to take things.

You might argue that I'm making an ideological argument but, linux has gained its popularity from sysadmins; not from developers or desktop users. Sysadmins value stability, simplicity and the ability to understand the system they are running. Systemd effectively removes all those features from the OS. Yes, it might make it easier for desktop environment developers to implement certain features but, the number of people that use linux as a desktop environment is laughably small compared to the number of servers running linux. So, basically, systemd is undermining the primary use-case of linux to appeal to an unlikely to ever grow user base (desktop users). Which is made even more bizarre in that it's primary developed by Red Hat: Practically the champion of linux as a mainstream server OS.

Basically, linux users don't want the OS to become a giant opaque monstrosity that can be prodded and observed but never really understood (like Windows).

Comment Re:Duh (Score 1) 699

That's a very level headed pro-systemd argument and, while I understand the sentiment, I can't agree with the approach that systemd has taken to accomplish this. In particular, letting an init system, strongly controlled by a single party, morph into an abstraction layer of the OS to such an extent that it's impossible to avoid it.

Comment Re:Me? (Score 2) 699

The problem with going to LFS is that it's a huge amount of work to maintain it. I ran an LFS based laptop for a few years and even wrote my own package manager to help maintain a level of sanity. LFS is an excellent learning experience and can be a great hobby but, sometimes you just want to type, "sudo apt-get install" instead of spending an afternoon building a tool.

Comment Re:Duh (Score 4, Interesting) 699

The problem is that it's *not* a modern init system. In fact, I'm not really sure how to describe systemd apart from, "An overreaching solution to a problem that never actually existed". I don't think there is a single thing I can do with a systemd enabled system that I couldn't do in a 2008 version of Ubuntu. So, apart from complexity and a variation of vendor lockin, what has the linux world gained by moving to systemd?

Comment Re:Unlike Toyota that requires FJ Cruiser... (Score 2) 207

This seems to indicate that the dealer has to provide the recall fix for free but doesn't have to pay for the damages that might have occurred because of the failure: It's possible that I'm not interpreting that correctly but, I've had recall work done on my FJ numerous times and never paid a penny for it. Presumably because the things that were being fixed hadn't caused any secondary damage.

Comment Re:They are idiots (Score 2) 330

I guess it's a matter of perspective. They've managed to conquer a small swath of barely ariable land, sell numerous ancient artifacts that they didn't discover and kill an infitesimally small percentage of westerners. And they did all of that using the technology of the "much more clever" westerners.

Comment Re:Dramatic speed increase? (Score 1) 37

I've never had the chance to use the Intel TBB stuff but, it looks like it's at least well thought out. The big thing with data flow programming is that it's very difficult to wrap your head around it. I've worked on a number of data flow projects and we've always built graphical tools to actually define the flow and then layout the underlying C/C++/Fortran/Assembly based on the graphs that we've visually created. Effectively, you create a visual programming language to control the flow, then use lower level languages to do the heavy lifting. Maybe TBB has that but, this ( seems like the typical kinds of things all data flow projects end up getting to. Once you go data flow, you realize you need a better editor, a more informative "compiler" and, especially, a better debugger.

Comment Re:Dramatic speed increase? (Score 5, Interesting) 37

It's often the case that if you can express your algorithms as directed acyclic graphs, you can get amazing parallelism out of them. Rather than painstakingly programming the algorithm to run in parallel using control flow constructs, you just define your algorithm as a graph, spin up a bunch of threads and tell all the threads to consume any node in the graph whose dependencies have already been computed. This type of thing started to become common in the late 90s with things like the LINPACK benchmarks. It was difficult to get the algorithm to scale well on high CPU count machines but, if you defined it as a directed acyclic graph and then built an algorithm to efficiently consume that graph, the scalability was shockingly good.

Even outside the AI aspects of the library, it looks cool in that it seems to provide a framework for defining data flow algorithms with the specific intent of reaching a high level of scalability. There have been tools to do this in the past but, they have frequently been clumsy internal tools and geared towards a specific set of algorithms. I've even seen someone heroically define the LINPACK benchmark as a data flow algorithm in SPARC assembly. This stuff seems really cool and fairly accessible.

Comment Re:Who cares? (Score 1) 386

It's not clear whether or not this is a troll but, being able to get a mortgage (and the interest rate of the mortgage) depends on your credit score. So, sure, once you have a mortgage, set a cron job to post "wasted" on your facebook account 3 times a day. Until then you have to do the bizarre credit dance and wonder if maybe one day the credit agency is going to datamine satellite imagery to see if you ever park within 10m of a pawn shop.

"What people have been reduced to are mere 3-D representations of their own data." -- Arthur Miller