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


Forgot your password?

Comment Not Really (Score 1) 261

I've been running Linux since kernel 0.99a (the first one that had networking that really 'just worked'). I can count the number of times an x86-based piece of hardware that I could ATTEMPT to boot an install medium on failed to actually install without some sort of effort (and in EVERY case I got the machine working by searching around online for a bit and adding a kernel boot param). This includes many different laptops. I think there've been a very few cases where some ancillary piece of hardware on a laptop didn't actually have a driver, but it was always something weird. I bought a newer Logitech USB headset last year, and never could get Linux to work with that, so its not that ONE HUNDRED percent of stuff always works, but the ratio is 99% at this point, even of new hardware.

Truth is there's enough people out there running linux on most hardware, often as parts of various products where the consumer never sees the OS and doesn't need windows, so that few vendors avoid Linux support anymore. Even weird stuff like my Chromebook, and various oddball laptops all seemed to work. Truthfully even if there's a weird peripheral on them someone has developed support for it.

Frankly its gotten to the point where you just don't even need to consider hardware compatibility, though certainly if I am going to build a machine or buy a printer or whatever I'll go find out how well the hardware support works and buy what is likely to be 'the best'.

While I'm clearly a 'Linux guy' I'm far from a ravening hardcore 'true believer' either. Its just that over the years, certainly for my purposes, its proven to be most useful. The fact that its relatively secure and entirely free of 'surprises' is a bonus.

Comment Re:My thoughts exactly (Score 1) 261

Maybe not, but we KNOW that MS is actively gathering information. I don't doubt that if you are an expert enough Windows guru there are policies and documentation somewhere to allow you to root it all out and make it behave as you want, but I can install FC23 and OOTB I'm pretty much certain its not doing something untoward. Nor will it be filled with crapware that some OEM added which totally defeats all security (MAJOR problem IME).

Just saying "nobody is ever safe" is pretty silly though. There's a reason we don't let children play in traffic. Some things are safer than others, a LOT safer.

Comment Don't do it. (Score 1) 168

I mean, if you're just doing your own personal projects, that's one thing, but if you're doing real hardcore team-level website/app development where there's a significant amount of work, division of work between team members, etc. then go on AWS or wherever, set up a trac server, install git and set up a git repo that's linked to your trac server, get Eclipse, install the mylyn plugin, etc. If you want to go whole hog set up a docker container that has a copy of your web server environment in it for local testing. Now each team member can pull a copy of HEAD, do their stuff, push it back, test locally, etc, and deploy to your development instances, etc. There are other plugins that will let you use Maven2, and stuff to integrate with AWS so you can basically run the whole lifecycle of everything from your IDE.

My guess is you can find roughly similar capabilities in some other IDEs as well, Eclipse just has the advantage of having a lot of support and many tools (though usually you CAN find a stand-alone tool that does any given task better than the corresponding plugin, the advantage of integration is pretty nice).

Now, there's SOME work involved in constructing this sort of environment. You can build up to it though over a few smaller projects.

Comment Re: PHP vs Perl (Score 1) 145

Oh, "let me design my own language, it will be the best" is just programmer peen basically. There's a very slow gradual advance, as well as slow changes in the usage patterns for code, which means that SOME new languages add some small increment to coding practices and whatnot, but I'm not seeing where perl6 does that. It doesn't top Erlang or even ANCIENT versions of Scheme or LISP in concurrency, and it doesn't top other modern scripting languages in any other respect AFAICT.

As for your other comments, the optimizer can't tell when there are two overlapping call signatures? Really? Who wrote that? They spent 12 years on it and that's as far as they got eh? Wow! I disagree that different calling conventions are good. It requires remembering how to do basically the same thing in multiple ways. If named parameters are best, they're best. If you need some to be optional or mandatory, then provide a syntax for that. As for standard positional arguments, you can always pass a NULL as an argument, always could and always will be able to do that.

Comment Re: PHP vs Perl (Score 1) 145

So you can get compiler warnings when you accidentally try to shadow an 'only' sub definition in the same scope when you are not using multis.

No other language needs this. In both perl6 and Java for instance it is illegal to have 2 functions of the same exact signature in the same scope, and multi doesn't change that (how would it). NOTHING is gained by multi, except added syntactic complexity and the need to revise existing code when adding a new method/function that has the same name as an existing one, which is fairly common. By itself this is trivial, but perl6 commits this same sin again and again in different ways, meaning you have remember many non-value-adding syntactic rules. Its just poor language design and smacks of some sort of 'ashcan design' where everyone stuck their nose in and added an extra bad idea.

why is there sub and method as separate things in the first place

Because calling conventions are customized to OO in methods -- you have an invocant, and unknown named parameters are, by default, ignored so you can easily subclass.

But again, other languages don't need this, and neither does perl6. If such calling conventions are 'good' then why not use them for all subroutines? Surely they aren't better for methods than they are for other function calls. Why not allow either style of call for the same function without needing extra syntactic noise? Surely a compiler can distinguish one type of invocation from the other! This again removes an entire extra keyword and in fact would also remove other related oddities.

and WHY is 'sub' changed mysteriously to '->' when the method is anonymous

anonymous subs using "sub" still work. '->' is a generic closure syntax which you may prefer if you like it.

OK, fair enough, I didn't see where 'sub' was still supported in this context, but that's fine. Personally I find '->' ugly and cryptic, but to each his own!

I'm having a hard time seeing what was gained

It's as much about what was lost than what was gained -- Perl 6 leaves behind a lot of the things that demanded a spirit of loyalty to put up with, like variant sigils, so it will be less irritating to a wider audience. The whole language is much more self-consistent, and things that would have required a complete overhaul of Perl 5 to implement have not had to contend with the obstacle of backwards compatibility.

Well, I certainly understand that perl5's sigil-based 'casting' is obtuse until you get used to it. I might become comfortable with perl6 in time, if I have some reason to bother. That's a big question though at this point. What exactly IS the argument for perl6? It certainly doesn't seem to bring anything radically new to the table. I doubt its simpler and cleaner than Ruby for instance, which I've also never really used, but would probably find more compelling right now today if I was told I needed to pick a modern scripting language (and being no fan of JavaScript). perl6 is certainly WAY late to the party. I doubt it is currently anything near as optimized as perl5, Python, Ruby, etc. It doesn't appear to have any revolutionary multi-threading/parallel processing magic that other languages don't have. It certainly lacks the sort of advanced features and concept that Erlang and similar languages present.

Honestly, its a bit sad. I liked the perl community pretty well, but I guess the world moves on. perl5 seems unlikely to acquire portability, usable multi-processing, or other really advanced features. Its still a decent language with wide support, but it seems almost inevitably doomed to slow obscurity in its little ever-shrinking niche. perl6 seems unlikely to thrive at this late juncture. I guess Ruby and Python have both long since absorbed the lessons of perl, as have other parts of the IT world. Certainly CPAN was a huge influence far beyond scripting languages. The world is better for having had perl, but I guess nothing lasts. perl6 seems more like a footnote or epitaph than something really new to me. Sorry if that's a glum assessment to a perl6 supporter, but I was one too, in 2003 or so...

Comment Re: PHP vs Perl (Score 1) 145

Well, perl has had a form of subroutine signature since forever, you can put sigils in quotes after the name of the subroutine, like sub fooBar($$@) (I think you can even do something like fooBar($foo, $bar, @baz) but the names don't matter). ALL that does is allow the compiler to let you elide the parens when you call the subroutine, like "fooBar $foo, $bar, @baz;" instead of "fooBar($foo,$bar,@baz);" which is not really the same thing at all, you still need the silly local variable incantation at the start of every subroutine. Its just some extra noise that could profitably be removed, and frankly being able to call subs without '()'s around the arguments is NOT a feature, its an excuse for bad code. If it enabled some really amazing syntactic wizardry I might shrug and say 'whatever', but it really doesn't.

Anyway, maybe 5.13 or whatever is the next perl5 has something else in mind for this syntax, I don't know. Frankly perl became too limited for my ambitions. Its a fine language for 50-100 line utility programs and modules, but there are tools out there that scale MUCH better and eventually you find that its just not cost-effective to stick with perl for larger projects. Not that I would use Python, Ruby, or PHP for any of those either, but for many of the same reasons. Maybe in the end that's why perl6 doesn't really excite me anymore. I was interested 10 years ago, but we've moved on since then. People doing what I did in say 2001 or so MIGHT find perl6 to be a slight improvement, maybe.

Comment Re: PHP vs Perl (Score 1) 145

That I can at least understand. If Perl was a PURE OO language it would be just built in, but given the way its an incremental feature that you can ignore, then it makes sense that there's SOME sort of syntactic "this is now an instance" thing.

This IS one thing that perl6 fixes, you have a more regular argument syntax. Of course there are some really, IMHO, stupid choices as well, like why do I have to go find other instances of the same sub/method and rename them 'multi' just because I now have 2 signatures? Or why is there sub and method as separate things in the first place, and WHY is 'sub' changed mysteriously to '->' when the method is anonymous? There's actually a LOT of other similar inconsistencies and bad code maintenance choice things I noted in just a cursory survey of perl6.

I don't know all the tricks, but it seems like several of the good features of perl5 went away, and several poorly considered or overly thought new things of more marginal use appeared. Simple scripts may be a little bit cleaner in perl6, I'm not sure, but I don't think overall its a drastic improvement over perl5. Some more advanced things like currying or implicit iteration MAY be a little more straightforward, but not by much. I'm having a hard time seeing what was gained, apart from function parameters. Couldn't we have just gotten those in 2002 and called it a day?

Comment Re: PHP vs Perl (Score 1) 145

I do have some bitches though. Its impossible to write a good code analyzer or even syntax highlighter for perl5 code. There are elements of the syntax that are obtuse even for people like me that have written literally millions of lines of perl code over 20 years. And aren't you really sick and tired of writing my ($self,$foo,$bar,$baz) = @_; YET? I know I sure am!

I write extremely clear and concise OO code in perl, but its STILL difficult to understand at a glance.

Comment Re:That old chestnut? LOL. (Score 1) 145

So true. I wrote some pretty large programs in Perl back in the day. It has some excellent features, but today I only just maintain existing software written in perl5, and meanwhile Python adopted all the best things from Perl, and mostly avoids a lot of the worst. Just the fact that there's a real standard for it and alternate implementations puts it on a different level. Perl was far ahead of everything else in 1995, and the Perl community squandered all of that.

Comment Re:That old chestnut? LOL. (Score 3, Interesting) 145

FORTH RULES! I wrote a FORTH the other day inside my Java Unit test environment to script all the JavaEE client tests. I mean literally I wrote a forth, it took a few hours. Its missing some features, ain't quite ANSI standard, but its real. No piece of software ever designed in the history of Man is as elegant as FORTH. Does everything perl can do, feature for feature, in 1/10,000th of the code.

Comment Re:Spiral compression waves (Score 1) 94

Exactly. They're actually RADIAL compression waves I'd imagine, and they DO 'wind up' to a certain extent, but they also don't propagate strictly radially, so the wind up can only go so far.

However, its not so much that they are 'waves of star formation' as that they are DENSITY waves. Material moving towards an arm speeds up, because the gravity of the denser arm pulls it in more quickly, and material moving OUT of the arm is slowed, so as stuff orbits the galaxy it spends more of its time inside these denser regions, the arms, than in the sparser gaps. Stir up a galaxy enough and the arms disappear, and you get an elliptical galaxy, some of which develop a different pattern of density waves, producing shelled ellipticals. None of this is really new, most of it was worked out at a general level 50 years ago. I'm really not sure why it suddenly became news worthy.

Comment Re:Backups. (Score 1) 168

Yeah, the system I use GPG encrypts each backup and pushes it out to a location in the cloud, along with a copy of the key (which is protected by a stupidly tough passphrase). That way I could upload it to a publicly accessible location with no worries (and in fact back in the dim dark days we did do that).

Comment Re:Backups. (Score 1) 168

I may have to play with that too. I don't have vast amounts of data, but when some of our stuff is off on the other side of WAN links it can be annoying to backup even 50 gigs of data sometimes. Particularly when you know you MUST have 95% of it in some archive somewhere already.

Slashdot Top Deals

The perversity of nature is nowhere better demonstrated by the fact that, when exposed to the same atmosphere, bread becomes hard while crackers become soft.