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

 



Forgot your password?
typodupeerror
×

Comment Re:Um... (Score 1) 145

I'm not sure about "perfect".

You can get a dedicated flight controller with better sensors for $20 and weighting under 2g. Contrast that with an iPhone that costs how much and weighs 129g?! Sure, the iPhone also comes with GPS...but again, $20 gives you a massively better GPS unit than an iPhone has. And of course...you've also got to add some kind of additional hardware I/O for the iPhone to talk to the ESCs (more weight, more cost).

Much of the rest of an iPhone just adds weight and eats power if used as a flight controller.

You might be able to make it all work if you try hard enough, but it would just be academic. I would never, ever be practical.

Comment Re:Has it been working so far? (Score 3, Insightful) 387

The linux kernel. It's in your desktops, in your web servers, in your cell phones, in your cars, in your televisions, in your game systems, in your embedded devices... if it were to suddenly go away, the landscape of modern technology would drastically change.

Web servers and cell phones, yes. The rest, not so much.

Realistically almost no one runs Linux on their desktop. Even Unix sysadmins lean heavily to Windows (or Mac). Windows with cygwin makes a more effective Unix workstation for most all uses than does Linux.

The embedded realm (including TVs) is dominated by BSD, for license reasons if nothing else. That's if they want/need a heavy weight OS; Most embedded systems either have no OS or a small real time OS.

The only game system that runs Linux is Steam Box.

And last but certainly not least, if Linux fell off the face of the Earth today, very little would change tomorrow. The BSDs are a drop in replacement for 99.9% of Linux use cases. And frankly, would do the job better: Linux is popular despite merit, not because of it.

Comment Why is this hardware? Why not just write an App? (Score 2) 94

Why not just run a web server App on your smart phone?

-No second device to buy, carry around, or keep charged.
-No second device to constantly "sync" with.
-Far easier to keep patched with security and feature updates.

Of course, that's putting aside all the issues around trying to run a web server on personal internet access accounts (cell, public wifi, home wifi, work wifi, any of it). The bandwidth issues of trying to share a video of your kids with your family alone will trash most any common internet connection, and that's if it'll be allowed at all (inbound port 80/443) or legal ("no servers on this connection!").

This project has Epic Fail written all over it.... So I'm sure in classic Kickstarter fashion it'll get funded 10x over it's target. Because, sheeple.

Comment Re:That's not the reason you're being ignored. (Score 1) 406

Got a link?

Generally speaking, being relaxed greatly reduces your chance and severity of injury. If you can, let your body go rag-doll if you know you're going to crash (easier said than done of course...).

"Bracing for impact" is the exact opposite of being relaxed.

If anything, getting mentally absorbed in a device likely reduces injuries. And if the crash is severe enough to cause a brain injury by hitting the seat in front of you, you're going to be hitting the seat in front of you no matter how much you brace yourself. There's a reason why cars have shoulder harnesses and airbags.

Comment Re:Bummer (Score 1) 63

I get what you're saying, but this project isn't likely to cause a major issue like the Phantom has.

What they are designing is going to need to be about the size of a Blade Nano QX. I've no idea how they plan to get all that technology in such a tiny quad, but assuming they do the "impact" of one of these hitting someone will be practically nothing. The micro/nano size quads just don't have the power, mass, or prop size do to significant harm (unless maybe, it actually hits you in the eye).

Comment Re:~/.cshrc (Score 1) 208

It makes sense, /bin/csh was the traditional default shell of BSDish systems.

But the default shell doesn't matter, because the default shell isn't used by C library functions like system(). /bin/sh is used, no matter what your "default shell" is set to. And some foolish folks decided to go ahead and replace /bin/sh with bash.

Comment Re:Preempting dumb discussion (Score 1) 318

Trying to brush off blame with the tired old nonsense that "Linux is just the kernel, man!", just doesn't fly anymore. Hell, it never really has.

The term "Linux" is well understood to mean a family of full, complete operating systems (libs, userland, and all). When anyone is actually speaking of just the kernel, it's qualified as exactly that, "The Linux kernel...blagh, blagh".

Comment Re:"could be worse than Heartbleed" (Score 1) 318

Sure, a double fork() && exec() pattern is ideal, but it's also significantly more code and complexity (read: fat thumb bugs) than calling system("/some/command &");

And before you say it, yes actually there are tons of use cases where forking a background process is a far superior method than any alternatives. It's one of the oldest and most common Unix programming patterns in existence. Programming doesn't really change much simply because you add "on the web" to the end of your use case.

Comment Re:"could be worse than Heartbleed" (Score 1) 318

The vast, vast majority of tools do not need significant "scaling". Often just throwing a heavy weight job in the background (eg, transcoding a video file) is, and always will be, significant. Especially if you've got an auto-scaling web farm that'll just expand under load anyway. system("/big/job &") all day long.

Sure, it'll never scale to YouTube levels, but it'll scale large enough for 99% of common use cases.

The "proper" alternative architecture using message queues, etc is massively more code, complexity, and resource cost. Great if you actually need it, nothing but overhead when you don't, and you typically don't.

Comment Re:This exposes systemic insecurities (Score 1) 318

You don't need to run a "full-bore shell program" to be vulnerable.

You simply need to use the system() function of any popular language (Perl, PHP, Python, Ruby, C, etc). The system() function executes /bin/sh -c to parse the string before executing it. You don't even need to pass any arguments. On every Linux distro /bin/sh IS bash. Game over.

The alternative to using a one line system() call is a few dozen lines of complex, easily screwed up systems programming as you navigate through fork(), exec(), dupe(), wait(), etc.

The real issue are Linux distributions deciding that bash was a suitable substitute for a minimal POSIX /bin/sh.

Comment Re:I think this is a good idea. (Score 1) 282

You try and throw it back and me and yet...Linux is one of the only "modern" production kernels that hasn't figured out auto-tuning.

Why is that do you think?

And why should I chose Linux, knowing I'll have to spend considerable time and expense to "tune" it, even for very common use cases, when other systems can tune themselves better than 95% of sysadmins and do so for free?

Comment Re:I think this is a good idea. (Score 1) 282

Better question: It's 2014, why the hell are you still manually tuning kernels?

I'm not saying you don't need to for Linux...I'm asking why you or anyone else feels this is an acceptable requirement? Is it just to keep Linux sysadmins employed?

Sure, for some incredibly unusual workloads we might not be able to expect the kernel to self-tune, but for the other 95% of typical uses they kernel really should be able to tune itself and do so far better than any human.

Seriously, why do people put up with schedulers that are so bad they not only can't self-tune...they need to be wholly replaced...and such "tuning" requirements are considered normal?!

Slashdot Top Deals

Real Programmers don't eat quiche. They eat Twinkies and Szechwan food.

Working...