Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:Make it DARKER dammit. (Score 4, Interesting) 145

by discord5 (#49163197) Attached to: Spock and the Legacy of Star Trek

What would it take to get it back in line with TOS? Maybe a dose of optimism and belief in conquering great evils and striving for a greater society. Maybe it just isn't a widely held set of beliefs anymore

I like to think that the decline of Trek is a combination of various factors. If we disregard TOS, the series that is most in line with that line of thought is TNG. Picard (in the series at least) holds those ideas in high regard and acts in nearly all episodes as a strong moral compass. The hand of Roddenberry is strong in that series, but Gene Roddenberry died during the making of TNG yet somehow Picard hasn't made a complete 180 and the show retained much of its popularity.

The change in the Trek universe is much more visible in the series of DS9, which sets an overall darker tone with the Dominion war. The point has been brought up before that DS9 battled for viewers with B5 where the tone in general about the future is far less resembling the Trek utopia, although comparing it to most modern scifi it's not all that "grimdark". To be honest, one of my favourite episodes in all of Trek is "In the Pale Moonlight", where Sisko basically goes against everything he stands for because it was necessary to get the Romulans on their side.

Once you get to Voyager, the change is irreversable. Voyager pretty much throws nearly continuity and Trek philosophy out of the airlock as Captain Janeway happily trods her way through the delta quadrant making alliances with the Borg, violating the prime directive in an almost action-hero kind of style, using warp 9 at an almost daily basis (despite it being forbidden in TNG by starfleet), contemplating genocide with the Borg, oh and in the series finale violates the temporal prime directive... It did make for good TV though. Compare Janeway to Picard (in the series) and you'll notice that they embody totally different ideologies. You could argue that over 70 years away from the federation they had little choice but to go with the flow, but just imagine Picard in that position.

A lot of Trek fans attribute the change in Trek to Rick Berman, but I think it's more complex. The audience has changed, and above all science fiction (or rather special effects) became relatively cheap to make. Trek suddenly had to compete with a lot more shows, and instead of focusing on storytelling the choice was made to focus on things like action and effects. Voyager is the best example of having a lot of characters they could build incredible stories about, but opted not to. They take on a Maquis crew, but aside from a few episodes it hardly gets mentioned what kind of problems this causes. Bellana as a half-human, half-klingon could have had so much more character development but barely got any aside from 2 episodes in 7 years. The only character to really get any character development was 7 of 9, and even there the plot always felt so underwhelming.

By the time Enterprise came out, I think most Trek fans were giving up on the franchise. I remember at the time that few people had something good to say about the show, so I skipped out on it.

As for the Trek movies. Picard in the TNG movies is no longer the Picard from the series. A complex man who upholds his principles and beliefs above all else was written into the role of an action hero,and in some movies even has a one-liner to finish off the villain. The TNG trek movies are action movies in line with the Trek universe, and I think the Trek reboot just makes the gap between the Trek ideas even bigger. I don't think they are bad movies, as long as you watch them as action movies and not as TNG Trek.

The problem with Trek, I think, is that the franchise is overused. The only way it can continue on and attract an audience is in a way that derivates from the original work but strays as far from it as possible. The traditional Trek audience won't be happy unless Picard 2.0 comes along, and the traditional Trek audience simply isn't as big as the generic-action-movie audience. With how cheap special effects have become, any new Trek series would have to compete with generic cheap scifi show X.

I think that for all purposes and intents, Star Trek is dead. There's not a lot left to do with the universe that fits into the Trek vision, especially if you want to keep a sense of continuity. Really, start something new that incorporates the philosophy of Trek, but dumps the setting. Trek has always had to carry its own history with it, which is what eventually lead to a ridiculous attempt at rebooting the Trek universe into a hyper-energized mirror of itself recently. It's a pity because we love the iconic things this series has given us, but at this point I think the franchise is far beyond salvation.

Comment: Re:sounds like a hoax (Score 1) 175

by discord5 (#49019735) Attached to: Hobbyists Selling Tesla Coil Kits To Fund Drone Flight Over North Korea

All of the money from this project will be used to extend the distance our drone can fly, so the more backers we have, the farther it will be able to go!

Ok, now I know it's a hoax/scam.

It's not a hoax, it's a hot air drone. Basically they're going to be burning all the money they got underneath the drone. If the pile is high enough and the wind is in the right direction, clearly it'll reach Pyongyang.

Comment: Re:Just remove the camera (Score 1) 324

by discord5 (#48882709) Attached to: What Will Google Glass 2.0 Need To Actually Succeed?

All Google needs to do is remove the camera. That way, it can still be used for notifications, searches of information and other overlays

The only applications I can think of where glass might work as a useful item actually all use the camera to do computer vision kind of applications. The appeal suddenly immensely decreases if it's unable to do that since what is left is just another interface for my phone or PC to show me messages I can see elsewhere irrelevant of any context.

An application I personally think would be useful is in large server environments. Imagine walking in to a serverroom and simply looking at a server to get a list of the name, IP addresses, its function, applications or virtual machines running on it, being able to view open (and perhaps closed) issues with the system. We already have plenty of software to view all that information with a browser, but it would be nice to have a way of viewing that sort of info just by looking at the server in question. Patch cabinets come to mind as well, etc etc.

The last thing I want to do is use this sort of thing as yet another way to take pictures, keep track of my appointments, see if I've got mail, etc. I've got perfect things for that: a phone, a laptop, etc etc. I really don't need more devices to manage my mailbox, in fact I'd rather have less of them as my mailbox already consumes enough time of my day.

Finally, I really don't want to go through everyday life wearing those things as I interact with people. For one shoving a camera in another persons face makes them quite uncomfortable, and wearing one on my face as I interact with people makes me kind of uncomfortable. I don't really see any practical use for glass in every day life. I don't want to read online reviews of the carton of milk I'm buying ("Very milky, 10/10, would drink again" -- xXxmilkmaster2kxXx), nor see recipes for lasagna when I'm buying tomatoes, not to mention how awesome it would be to see every bit of info in my field of vision scanned for possible advertisement opportunities.

I think there's a lot of useful applications that lie in the realm of augmented reality, most of which you need a camera for to do computer vision type of stuff. But at the moment from what I gather Glass is underpowered CPU wise (and tbh, I didn't expect anything else) and has terrible battery life, so the sort of thing I hope to someday see is probably far off. Sadly, most of the types of applications I keep hearing are the same stuff I do with my phone, and I don't quite need that on my face to be honest.

Comment: what it is and isn't doesn't matter to the public (Score 2) 88

by discord5 (#48460071) Attached to: Revisiting Open Source Social Networking Alternatives

I was surprised to see so many public figures and media entities jump on board — mainly because of what Ello isn't. It isn't an open source, decentralized social networking technology

Public figures and media entities don't give a flying fuck what it is or isn't. It's a matter of "can we monetize?" and "holy shit, look at that untapped audience". Things like "open source" and "decentralized" are the things only we nerds care about, and even in that group we find ourselves often in the minority.

If you want to build that social network utopia and get it to see some actual usage, you'll need to have a clear advantage and be able to get everyone and their grandma to move away from facebook, twitter and whatnot. For a media entity "decentralized social network" means "unreliable demographics" and "open source" sadly still means "not easy to monetize". Aside from that, you also need a certain momentum to build up, and have features that someone else doesn't have. Google+ is a perfect example of not being able to convince the greater public that you've got a better offer.

Personally, I can think of hundreds of more interesting hobby projects than hacking together an open source decentralized social network. But if you find it interesting, please do contribute code/documentation/fleshed out ideas to the community. Happy hacking!

Comment: Re:Secure pairing is hard (Score 1) 131

by discord5 (#47504003) Attached to: The "Rickmote Controller" Can Hijack Any Google Chromecast

This is a general problem with devices that are "paired". How do you securely establish the initial connection, when neither side knows anything about the other?

The problem isn't the initial connection really. Sure, there's an attack window there, but if it weren't for the actual problem it wouldn't have been as easily exploitable as it appears to be. The problem is that it is trivial once the Chromecast is connected to the WLAN to force it to reconfigure.

The Youtube video of his presentation (no transcript, sorry, go listen to it in the background while doing something else) makes it clear that it's trivially simple to get the device looking for a suitable partner again. If I understand it correctly the attacker sends one (or several) deauth frame(s) to the network and within 5 seconds the Chromecast will start looking for a new network at which point the attacker can take over control of the device.

The thing is, this was a userfriendly feature for when you're using your Chromecast device on other networks. If the developers had required a physical button press (on that nice reset button would've been fine), the attack window would've been just during the pairing, which is a much smaller attack window. While it doesn't take away the pairing issues you mentioned, but the beauty of this attack really lies in how easy it is to make Chromecast hop onto another network.

Semi-secure systems involve things like creating a short period of temporary vulnerability (as with Bluetooth pairing).

Which is the case as far as I understand it. The chromecast is vulnerable until it is configured. The attack just makes reconfiguration trivial because there's no physical intervention required.

Comment: Re:Fun Factoid (Score 1) 435

by discord5 (#47476761) Attached to: FBI Concerned About Criminals Using Driverless Cars

The promise of having virgin subordinates in the afterlife is not a traditional Islamic belief.

Oh, are you one of those people who reads the Onion and is outraged at how factually incorrect their articles are? I'm sorry... For the record, I don't think there's a JihadBot 3000 prototype either. So don't spread that as truth either...

Comment: Re:Automation is killing jobs faster than ever (Score 4, Funny) 435

by discord5 (#47468079) Attached to: FBI Concerned About Criminals Using Driverless Cars

Even suicide bombers are being rendered useless.

It's a matter of cost-cutting. Those virgins every holy warrior gets in the end cost a lot of money and aren't really contributing much to the cause themselves. The holy warriors themselves could unionize, but their union membership is rather short lived by nature. Aside from the membership problems, what exactly would they do? Threaten to blow themselves up? I'd explain into detail on the soon to be introduced JihadBot 3000, but the projects development costs have gone through the roof, and the prototypes have all blown up for some reason.

Pardon my stereotyping...

Comment: No good answer (Score 1) 536

today's rising star could quite easily be in tomorrow's dustbin

Well, at some point Perl was a rising star...

No matter what you're going to pick, it won't stand the test of time in the end.

  • Perl? Dead, done for, the perl community invited to the funeral but the refused to come since they were too busy organizing their next YAPC and having fun.
  • PHP? Waiting to be killed off. CVE-2015-0001 will classify the entire PHP codebase as exploitable, and in a desperate attempt to fix things, the developers will just delete the entire repository except for the mysql_real_escape() function.
  • Ruby? Dead because of scalability issues. The Ruby community collapses onto itself trying to attent Perls funeral, but somehow get lost and finds itself at YAPC wondering why the Perl community didn't even bother showing up at the funeral.
  • Python? Dead because of GIL, and it's either running Jython or IronPython, and nobody wants to sleep with Oracle or Microsoft that badly.
  • Java? Death by 3 and 4 letter acronyms and frameworks of frameworks. Research has shown that long term webdevelopment in Java is considered harmful to your sanity.

Kidding aside, look for a set of qualities in whatever language/framework you want to use:

  • Does it make it easy to do what you want to do?
  • Is there an active developer and user community?
  • Is there decent documentation?
  • Does it offer a SIGNIFICANT advantage to port your existing stuff to this language/framework over the currently used language/framework? (Time being money, and all that)
  • After starting a (small) test-project with it, do you feel confident that it meets your standards for doing real work with it?

I know that it's probably generic bullshit you're getting from me, but you're going to get a thousand answers all screaming at once "Pyramid" "Django" "CakePHP" "CodeIgniter" and what not and unless you take a look at the languages and frameworks and see what people are / have been building with it you'll be none the wiser. Pick something you see yourself maintaining without pulling out all of your hair in the next couple of years.

Comment: Re:Yes, Perl is indeed dead and rotting (Score 3, Informative) 283

by discord5 (#47304351) Attached to: Perl Is Undead

I moderated in this article, but this is something that I'd like to talk about for a bit, even if only anecdotal...

Perl 5 is still charging full steam ahead in every sysadmin group I've been around. I know there are python advocates out there, but I have only encountered ONE major IT shop that is completely (or nearly so) python driven (and it happens to be Guido's employer -- hardly a good example)

Over the past 8 years my own usage of Perl in writing code has declined to zero. There has been a mentality change over the years in the shop I work in, and where we used to grab for Perl by default as a quick'n'dirty duct-tape & MacGuyver language, we now exclusively rely on Python. I think there are several reasons for this shift.

The most prominent one to me personally is that other languages have adopted CPAN-like repositories. I don't know about the statistics of numbers of modules, active development, number of commits, etc etc, and put bluntly I really don't care. Although these statistics are interesting into disseminating how active a language is to its developers, to me as a user of the language it only matters if a module is maintained and does what its supposed to do. The thing is, for most of the things I used to use Perl modules for, I now use Python modules, and can say "Well, it's good enough".

Our development teams composition has also changed. A lot of our older generation of programmers/admins have retired or switched jobs, and a lot of younger people were hired to replace them. The younger generation is definitely more familiar with Python, Ruby and other scripting languages than it is with Perl. The incentive for learning Perl has become a lot smaller. Perl was the de facto language for many when writing a CGI script, but then RoR and AJAX happened. While over time Perl adapted (think Catalyst and Dancer) other languages have adapted as well. Look at all the wsgi applications and frameworks in Python.

Our investment in Perl itself was more of the kind where we used a set of scripts to change data from format A to B at which point our Java and/or C++ code takes over, or some tools to deal with our logs, etc. The switch to Python for these tools was gradual (but quick) process, and we found ourselves not looking back. I can't really say that we were/are heavily invested in Perl or Python, but for day to day usage Python has completely taken over. Who knows where we end up in another 8 years from now?

Lastly, if you were to go around our shop, asking people what's new about Python 3 you'll get pretty much right answers. If you go around our shop asking people what's happening with Perl 6, you will get a blank stare. I remember clearly how Perl 6 was going to become the best thing since butter on toast, ... There was general excitement about it all, and then there was a whole load of ... well... nothing. We're 11-12 years further and there's still no sign of Perl 6. What the hell happened there?

Perl has only been dominant in the sysadmin space for less than 15 years ... I wouldn't be surprised if it lasts at least another 10 more.

I don't doubt that Perl will be around for a whole lot longer. It has assembled a group of dedicated die-hard users and developers over the years, and in general it has a great community. There are older, more horrible languages that are still alive today, so I doubt Perl will be gone anytime soon.

However, while my entire post is anecdotal, I do think the Perl community is deluding itself a bit. The talk in the video (I actually listened to it in the background while working on something) mentions a lot of statistics that are interesting to the Perl developers and maintainers, but are hardly and indicator of usage or adoption. The more interesting part of the statistical talk was about the general decline of jobs available for scripting languages in favor of newer technologies, but even those statistics in general don't speak much about usage and adoption.

FWIW, may Perl be around a long long time. Having more tools at your disposal is never a bad thing.

Comment: Re:No... (Score 2) 533

by discord5 (#46959279) Attached to: Ask Slashdot: Practical Alternatives To Systemd?

I was more thinking about starting postgres before the server that uses that DB to store its stuff.

Allow to go off on a tangent here, but most of the setups I deal with keep databases and webservers on separate machines. Today we've got virtual machines coming out of our collective asses so even developers start separating their services from each other. What you're talking about is dependencies and how to deal with failure of a service. That goes far beyond the scope of what systemd can provide, since it's so cheap and easy to run stuff on different (virtual) machines these days. However, I realize that you're using this as an example, so I won't really press on the matter other than that this is the poorest example you can choose.

But it does speak to part of the problem. All I continuously hear about systemd as the greatest advantage is solving the "complex boot order" dependency problem, parallelizing boot scripts and decreasing boot-time. To me, as a sysadmin: I DON'T care. I'm pretty sure that 90% of the servers I have running take a longer time in POST than they do in booting. If I reboot something, I'm taking it OFFLINE. I'm not sitting there crossing my fingers "Please come up quickly", but I've got a failover setup and another machine has taken over before the server is rebooting. And "complex boot order" really? Is that really that big of a concern? I really hope you don't have to manage 500+ servers then, because you'll be in for a surprise on complexity.

This brings me to interesting questions that I hear nobody talk about. If you're doing failover type of things, you're bound to end up with heartbeat/corosync/... + pacemaker & co. As a sysadmin, for me those things are extremely important. Last time I checked (and granted, that was a while ago), none of these actually had a proper way to deal with the impact of systemd. I'm sure that the people behind the various failover solutions are working on it, but last time I checked I saw very little in official documentation, and only the occasional headscratching on mailinglists.

To me, systemd presents quite the challenge, with consequences even outside of the technical side of things. For a while I'm going to end up in a mixed environment, forced to write two sets of operational procedures, disaster recovery scenarios, etc etc. I'm going to have to retrain people on how to read system logs, have to deal with systemd's quircks (no offence, all software has its peculiarities, and so will systemd), and will probably have to completely rethink how we do failover scenarios. And all I gain, what I'm really interested in is... cgroups...

Projectors, usb disks and sticks, whatever ... Those things have no place in a serverroom, and I don't care about it. And let's be frank, nobody in a corporate environment gives a shit about linux on the desktop. The few companies that I've been at that have linux on their desktop are small businesses with a near complete tech workforce.

Why would you want to convert rich information into a string and shove it down a pipe before you make use of it?

I think I know the answer to that question. Some environments need to archive their logs, for a long long time. Some things are more complex than a "simple" local syslog setup, and with that complexity comes a set of tools that often organically grows over the years or follows certain administrative procedures inside a company. In such environments, change is a difficult process, not because of people but because of corporate inertia and red tape bullshit. And it's great that systemd provides a syslog fallback for us text-junkies, at the very least it buys time...

The other side of the medal however is, nobody is really having a problem with text logfiles. The examples I continuously see are so contrived, or focussed on "the linux newbie" that it just reeks of a developer looking for something to do. My biggest frustration with logging on unix isn't "I don't know where to look" or "I don't know what to look for", but "This logmessage is meaningless without several Google queries". Any person who knows about /var/log can relatively effortless find the errors they're looking for, but an error message like "Connection reset : read() returned 5 bytes" says very little about what is wrong unless you're a developer of that particular daemon. No matter what abstraction you put into place for logging, it doesn't really solve the issues I'm dealing with.

So please enlighten me: How do you kill apache with all the php/ruby/whatnot crap it directly or indirectly spawned? With systemd it is just one convenient systemctl stop apache

service apache stop. And when all else fails : kill -KILL .

Don't get me wrong, but if you've got rails or pyramid, django stuff you should either be using the correct apache modules, or documenting how the two communicate with eachother (like with fcgi or some proxy solution or whatever). If I stop apache, I expect apache to stop. If apache is spawning stuff it's not supposed to, I get off my chair and walk over to the developer that wrote crappy code, or poorly documented how to start and stop his stuff and find a way to fix it. If it becomes the default behaviour of your apache deployment, clearly it's nowhere NEAR production ready.

Having said that, sure stuff goes wrong. I'm well aware of that, on a daily basis. But I've never been unable to solve these kinds of small issues before. There are bigger issues that haunt me than process management, and systemd isn't going to help me with those. If process management on a single machine is a sysadmins worst concern, I fear for his career in a real environment.

Most are a real improvement over the existing tools to manage hostname/date/time/timezone/locale/service/network/efi boot loader/virtual machine/whatnot. At the very least they are way more consistent in how they work and they work on all modern Linux distros in the same way. That was never possible before.

Give it some time. Let the distributions do fun and neat things by wrapping systemd's tools with their own scripts and you'll have the same fragmentation that you have now. This is like that story where there are 10 standards, and a guy says "I'm making a standard that unifies all these standards!". Result: you now have 11 standards. Again, don't get me wrong, I like the idea of having a standard way of doing things, but there have been so many efforts in that regard, without all too much success, or relatively quickly heading into different directions.

Linux in the end doesn't have a single set of developers, but hundreds of distributions, each with their own developers, each with their own collective ideas, so it's guaranteed to happen.

everybody will be using systemd (including gentoo and slackware)

I haven't used slackware in ages, but I think you're underestimating their core audience and developers, and their resilience to change they deem unnecessary.

Finally, I'd like to make a couple of remarks in general about this whole topic. I hardly ever comment on systemd, and since I've written all of this I might as well add that.

First of all, I'll admit, I'm actually really interested in it. I haven't had the time to play with it, break it, customize it, and do my thing with it, but I definitely aim to do so relatively soonish. To say the very least, it is an ambitious project and it certainly is making waves. However, I am somewhat concerned with the scope of systemd far outgrowing what seems to me to be reasonable for an init system. These discussions have been going on for a while now, and my concerns aren't being reassured by the arguments in favor of it, simply because I have no need for these features or find them to be non-issues in my use of Linux.

For me professionally, I'll have to deal with it at some point in the future, so it's one of those things where I'll (albeit somewhat grudgingly) adapt. I do however think that when the major distributions have released their new systemd based versions, what you're seeing today will only be a fraction of the criticism the project will have to deal with. People are averse to change, especially if it's change for something they've been used to for years. If systemd breaks in unexpected and interesting/fun ways, I expect quite a bit of backlash. If systemd should fail hard, I kind of fear for the consequences. The feedback I'm seeing from a lot of Fedora users is not the most flattering either, although I suppose some of it is blatant trolling.

I've seen sysvinit replacements come and go, including such wonderful examples as DJBs attempt at reinventing the wheel, which had the wonderful side effect of making sysadmins having an unexplainable urge to bang their heads against a wall at random intervals. Each had their set of problems, imperfections and fun and interesting new ways to break. While past experience shouldn't be an excuse not to try out new things, I do tend to be guided by that experience. Systemd seems like a system that is far more complex and encompassing than any of the other sysvinit replacements I've used in the past, and considering that complexity goes hand in hand with bugs and looking back at my previous experiences with sysvinit replacements, allow me to be somewhat skeptical and not the first to take the plunge in an operational environment.

I cannot draw a cart, nor eat dried oats; If it be man's work I will do it.

Working...