Yeah, I know the program inside and out. There is a very straightforward bug. Any time you select one of the styles from your library, LO is liable to just arbitrarily set the font, point size, and other font attributes to some incorrect values. These will generally be values that are used in SOME style SOMEWHERE in the document. If you are going by the default styles that exist in any document when you open it, the general ones that form the default template, then setting something like 'h1' will USUALLY give you 16 point bold liberation sans, but because liberation serif is the body text font, it MAY select that instead! It may select 14 point (which is the h2 and h3 point size) as well, or even 12 point (body text) or possibly some other point size. The same is true for setting ANY style, and it will usually get 'stuck' for a while, insisting on the same incorrect values for a while, and then just arbitrarily reverting to something else! Beyond that the program gets VERY confused about what elements have what styles under editing. I constantly find that even though various parts of the document have the correct font, size, etc that magically LO now considers them to be part of some heading or other element style that is adjacent. This usually manifests when you build a TOC and all sorts of garbage shows up in it. You can't just easily fix this crap either, you basically have to just find a point in the document beyond the mess where its not screwed up anymore and systematically cut and paste text from the 'bad' part until you can delete the whole mess. In the latest (5.x) series LO releases I THINK they've FINALLY squashed this bug, but its hard to say for sure.
Believe me, I've used this and OO before it for MANY years, since OO was first released. I know all the OO/LO applications reasonably well. I haven't even owned a copy of MS anything since the 90's. Although I don't handle a lot of documents that require using the most complex features of LO write, I certainly have quite a few documents, templates, etc. This is a universal and perpetual problem with write. Has been for years. Really, if I was a little less busy and the code base wasn't such a vast and frighteningly complex beast I'd go in and try to fix it. I suspect there are just one or two basic data structure issues, maybe its a concurrency bug in the code that manages styles. Perhaps its COHERENCY, that could explain how if you were say on a single core machine or certain processors with certain cache design you might not even see a problem. It sure don't work right on an I7-4770S...
I love it when people come out with this crap "well, it didn't happen to me, so its BULLSHIT!" Dude, I have MANY documents written in OO, LO, etc of various vintages and types. It happens in ALL of them, and its happened for at least the last 2-3 years. This isn't open for fucking debate, I can demonstrate it at abso-fucking-lutely any moment in time on almost any document. I know ALL ABOUT styles in LO, its A BUG. I don't know exactly WHY it especially plagues me and not you, but calling something bullshit that I can see with my own eyes will just get you told you are full of crap.
Yeah, its kind of a tossup between DocBook and LaTeX. If you have nothing but text, code samples, and that sort of stuff, and maybe a very few simple illustrations, then DocBook is great, and has some real advantages in being easily transformed (this is a real boon if you were to for instance want to convert the text into Wiki pages, a very straightforward XSLT can do that, whereas with LaTeX you're kinda at best going to need multiple steps that each probably introduces some errors). LaTeX OTOH certainly has the advantages in terms of orthography, complex tables, etc.
I really have come to the conclusion that if what you REALLY want is high quality PDF output, and/or output to print, where you have any kind of more elaborate layout, Scribus is the better tool. I like the idea of doing it in LaTeX, but the number of round trips you need to make is just a killer.
Libre Office's styles IN THEORY are OK, but they DON'T FUCKING WORK, the implementation of that (and a billion other things) is so buggy its just plain unusable. I have 50 page manuals. The actual font, point size, etc for each logical style is UTTERLY RANDOM, if you go to a document, hit enter, select "H3" (for example) LO picks ANY arbitrary font, point size, etc with no rhyme or reason to it. This has been true for at least the last 5 or 10 versions of the software. Try to make a horizontal rule in LO (or OO, its no better). You simply cannot do it without using some truly bizarro-world hack. Frames, especially if they contain tables, are an UTTER DISASTER (and putting a table inside a frame is the ONLY way to make text flow around it, its not like you can avoid doing this in anything but the simplest document). I could go on for hours. The program is a bleeding disaster. Its been years since I used Word, so I can't even begin to comment on what the situation is there, but LO is frankly just shit. Again, its fine for writing a 5 page memo where you just don't really give a crap what the formatting is or if everything is buggered, beyond that you need something like LyX, Scribus, or just plain write your stuff in LaTeX and live with the pain of constantly re-exporting it as you tweak every little thing into shape. At least you CAN get what you want, and Scribus actually has pretty good style management, for what it does. Problem with any of these tools is they're just not that good for WRITING. My current solution for serious writing where layout quality is going to matter is to just write the bulk text in LO and simply cut and past it all back into text frames in Scribus. You can do pretty large dumps of text if you know how, so its not THAT bad. The lesson is, each tool for what it is good for, and word processors are NOT good for doing quality layout, you have to use a separate application (I'm sure the various commercial DTP tools will work well too, but Scribus really is pretty good).
Until they experience the SHIT that is Libre Office's failed attempt at styles. If you want to write something longer than 5 pages, its utterly useless.
For example, you can freely SSH from inside China to anywhere outside, except maybe some completely blocked IP address ranges. Certainly things work fine if you SSH to any of the AWS locations.
So, fire up a nano instance before you go to China, and run a proxy server on it. I think I used squid last time, but there are a billion choices. Then simply port forward localhost port whatever to your proxy, and tell the browser to find the proxy at localhost on that port. My advice is to set your proxy up to listen on 2 or 3 ports, and set up a couple of nano instances with different elastic IPs, just in case one gets blocked (this seems to randomly happen once in a while for a short time period).
I had no problem at all using this setup. It was usually reasonably snappy too, though YMMV depending on where you go, etc.
Obviously you can resort to more elaborate schemes like Tor, but frankly I wasn't interested in being that obtuse. DO remember, the Chinese govt employs many fine hackers. I know for a fact they cotton to these kinds of things and while they may or may not bother to probe your systems, they DO sometimes break in and play various games. This is another reason to use an AWS instance, its utterly disposable. If you use a machine on your own network, you're just inviting in unwelcome guests who can be rather hard to get rid of.
Yup, and as a long-time Vermonter I can say that Vermont is not generally a place that is run with idiocy and hype. Its a place where money has little part in politics and people get what they want. Like one of the most livable places on Earth, and one that is leading the way into the future environmentally, socially, etc. It has a fair number of issues too, but here we have a very classic example of how government FOR THE PEOPLE works, vs how government FOR THE BANKS works. Well, heck, even the US Senate isn't totally corrupt yet, heh.
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.
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.
Windows will never really be safe, you have no idea what the heck MS is up to today, and what the next service pack will do. Just install FC23 or whatever and be done with it.
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.
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.
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...
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.
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?
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.
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.
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.
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.
Helium 3 is NOT A VIABLE FUSION FUEL, PERIOD. There is no such thing as Helium 3 fusion power, it simply cannot be viable. Where this idiotic notion of 'Lunar Helium 3' came from I don't know, but people should frigging do a tiny bit of basic research before they blort out this kind of nonsense.
3He fusion requires temperatures on the order of 10 BILLION Kelvins (Celsius), and the reaction rates are so low that the smallest viable reactor size would be on the order of a 100 gigawatt power plant.
Assuming we were able to build a tokamak that was commercially viable (which is unknown) then it would require something like an equally large step to reach 3He-D fusion. Not to mention the need to find the 3He, and Lunar mining would NOT be cheap.
p-B fusion is a MUCH more viable target, maybe not as cute in terms of being aneutronic, but VASTLY easier to achieve. Nobody is going to achieve Helium 3 fusion in this century, that's almost a given.
Exactly. How long will it be before such people start to just vanish into some black hole somewhere. If that doesn't work then their family, friends, etc will likewise suffer. This is always the last resort of the more powerful to the weaker. That's what being weaker MEANS, you can't protect yourself.
And if the tactic does work? It will just become another tool of the scumbags. Turds always float to the surface.
If I could make a mechanical calculator at that scale, then I could just as easily make an electronic one, at that scale. The problem is the "manufacturing issues" they talk about are the same challenges that thwart building microelectronics on the same scale. Solve one, you solve the other, and electrons are a LOT smaller than rods, there's very little chance rods will outperform electronic or electro-optical gates of similar scale.
Well, we have the ability to map a very small number of neurons. Actually do we even have that? We still don't EXACTLY understand how the potentiation of each synaptic junction works. There are something like 700 TRILLION of them in a human brain too, so we're not even remotely close, even assuming we can determine the weight for each one individually, to scanning even a tiny fraction of an actual brain. We couldn't even do that fruit fly, so even assuming we know where the synapses are that's like having just the hardware but not the software. And if you don't know how the things work at some higher level then you're going to actually have to measure the weight of each of those 700 trillion junctions to create a human brain sim. I'm guessing, but I think we're a LOT more than 30 years from being able to do that. Just think of it in terms of being adatabase problem. 700 trillion records? Yeah, good luck! In every respect our capabilities obviously fall far short, and even things like mice, heck even fish, are WAY beyond our reach there. So I think there's a huge amount of basic work that comes before even worrying about actual brain sim itself. At least that's how I see it, and that's STILL assuming that brute sim is a better investment than figuring out the principles and building more abstract models. By the time you get your brute force sim to work I may well be able to implement a more abstract one with 1 millionth of the effort.
But of course we don't know. I agree with you on this, Markram's way will cost a boatload more than EUR 500 million. I'm not so sure its WORTH that boatload, and I would want to know before going down that road at all, at least very far. With simply CNS sims there's almost surely things to be learned, but it is much less clear there's a real value proposition with higher organisms.
I think you are presenting a false analogy at multiple levels here. We might say today that maybe the world progressed faster to steelmaking one way vs another, but AT BEST that's 20/20 hindsight, you can't actually prove it, the analogy shows no particular connection with AI, etc. There was no 'plan' to 'get steelmaking' this is the real world not Civ IV tech trees, and people 1000's of years ago didn't even have a concept of progress as a general thing. Nor is anyone proposing that we halt everything, Markram's project is only one possible way of advance, not the only way, so you've got an excluded middle AND a red herring in there as well! But really, its mostly just a limited analogy. I don't think we can know how good or bad it is right now.
Are we really that much cleverer than cavemen throwing rocks in fires? Maybe, but not cleverer than bronze age metalurgists. In terms of what we know about how brains function who's to say we're much ahead of them at all?
Overall I think we're not in huge disagreement. I think brain simulation WILL continue. I think its likely to be a bit less grandly ambitious than Markram's for a while. I think I'd simulate a C. Elegans CNS first, then maybe a Planaria worm, and then perhaps some higher invertebrates, simple chordates, etc. Its going to be a good solid 30 years before the raw compute power exists to simulate a human brain anyway, maybe longer, so there's not that much of a rush if you ask me.
Slashdot Mirror
Yeah, I know the program inside and out. There is a very straightforward bug. Any time you select one of the styles from your library, LO is liable to just arbitrarily set the font, point size, and other font attributes to some incorrect values. These will generally be values that are used in SOME style SOMEWHERE in the document. If you are going by the default styles that exist in any document when you open it, the general ones that form the default template, then setting something like 'h1' will USUALLY give you 16 point bold liberation sans, but because liberation serif is the body text font, it MAY select that instead! It may select 14 point (which is the h2 and h3 point size) as well, or even 12 point (body text) or possibly some other point size. The same is true for setting ANY style, and it will usually get 'stuck' for a while, insisting on the same incorrect values for a while, and then just arbitrarily reverting to something else! Beyond that the program gets VERY confused about what elements have what styles under editing. I constantly find that even though various parts of the document have the correct font, size, etc that magically LO now considers them to be part of some heading or other element style that is adjacent. This usually manifests when you build a TOC and all sorts of garbage shows up in it. You can't just easily fix this crap either, you basically have to just find a point in the document beyond the mess where its not screwed up anymore and systematically cut and paste text from the 'bad' part until you can delete the whole mess. In the latest (5.x) series LO releases I THINK they've FINALLY squashed this bug, but its hard to say for sure.
Believe me, I've used this and OO before it for MANY years, since OO was first released. I know all the OO/LO applications reasonably well. I haven't even owned a copy of MS anything since the 90's. Although I don't handle a lot of documents that require using the most complex features of LO write, I certainly have quite a few documents, templates, etc. This is a universal and perpetual problem with write. Has been for years. Really, if I was a little less busy and the code base wasn't such a vast and frighteningly complex beast I'd go in and try to fix it. I suspect there are just one or two basic data structure issues, maybe its a concurrency bug in the code that manages styles. Perhaps its COHERENCY, that could explain how if you were say on a single core machine or certain processors with certain cache design you might not even see a problem. It sure don't work right on an I7-4770S...
I love it when people come out with this crap "well, it didn't happen to me, so its BULLSHIT!" Dude, I have MANY documents written in OO, LO, etc of various vintages and types. It happens in ALL of them, and its happened for at least the last 2-3 years. This isn't open for fucking debate, I can demonstrate it at abso-fucking-lutely any moment in time on almost any document. I know ALL ABOUT styles in LO, its A BUG. I don't know exactly WHY it especially plagues me and not you, but calling something bullshit that I can see with my own eyes will just get you told you are full of crap.
Yeah, its kind of a tossup between DocBook and LaTeX. If you have nothing but text, code samples, and that sort of stuff, and maybe a very few simple illustrations, then DocBook is great, and has some real advantages in being easily transformed (this is a real boon if you were to for instance want to convert the text into Wiki pages, a very straightforward XSLT can do that, whereas with LaTeX you're kinda at best going to need multiple steps that each probably introduces some errors). LaTeX OTOH certainly has the advantages in terms of orthography, complex tables, etc.
I really have come to the conclusion that if what you REALLY want is high quality PDF output, and/or output to print, where you have any kind of more elaborate layout, Scribus is the better tool. I like the idea of doing it in LaTeX, but the number of round trips you need to make is just a killer.
Libre Office's styles IN THEORY are OK, but they DON'T FUCKING WORK, the implementation of that (and a billion other things) is so buggy its just plain unusable. I have 50 page manuals. The actual font, point size, etc for each logical style is UTTERLY RANDOM, if you go to a document, hit enter, select "H3" (for example) LO picks ANY arbitrary font, point size, etc with no rhyme or reason to it. This has been true for at least the last 5 or 10 versions of the software.
Try to make a horizontal rule in LO (or OO, its no better). You simply cannot do it without using some truly bizarro-world hack.
Frames, especially if they contain tables, are an UTTER DISASTER (and putting a table inside a frame is the ONLY way to make text flow around it, its not like you can avoid doing this in anything but the simplest document).
I could go on for hours. The program is a bleeding disaster. Its been years since I used Word, so I can't even begin to comment on what the situation is there, but LO is frankly just shit. Again, its fine for writing a 5 page memo where you just don't really give a crap what the formatting is or if everything is buggered, beyond that you need something like LyX, Scribus, or just plain write your stuff in LaTeX and live with the pain of constantly re-exporting it as you tweak every little thing into shape. At least you CAN get what you want, and Scribus actually has pretty good style management, for what it does. Problem with any of these tools is they're just not that good for WRITING. My current solution for serious writing where layout quality is going to matter is to just write the bulk text in LO and simply cut and past it all back into text frames in Scribus. You can do pretty large dumps of text if you know how, so its not THAT bad. The lesson is, each tool for what it is good for, and word processors are NOT good for doing quality layout, you have to use a separate application (I'm sure the various commercial DTP tools will work well too, but Scribus really is pretty good).
Until they experience the SHIT that is Libre Office's failed attempt at styles. If you want to write something longer than 5 pages, its utterly useless.
For example, you can freely SSH from inside China to anywhere outside, except maybe some completely blocked IP address ranges. Certainly things work fine if you SSH to any of the AWS locations.
So, fire up a nano instance before you go to China, and run a proxy server on it. I think I used squid last time, but there are a billion choices. Then simply port forward localhost port whatever to your proxy, and tell the browser to find the proxy at localhost on that port. My advice is to set your proxy up to listen on 2 or 3 ports, and set up a couple of nano instances with different elastic IPs, just in case one gets blocked (this seems to randomly happen once in a while for a short time period).
I had no problem at all using this setup. It was usually reasonably snappy too, though YMMV depending on where you go, etc.
Obviously you can resort to more elaborate schemes like Tor, but frankly I wasn't interested in being that obtuse. DO remember, the Chinese govt employs many fine hackers. I know for a fact they cotton to these kinds of things and while they may or may not bother to probe your systems, they DO sometimes break in and play various games. This is another reason to use an AWS instance, its utterly disposable. If you use a machine on your own network, you're just inviting in unwelcome guests who can be rather hard to get rid of.
Yup, and as a long-time Vermonter I can say that Vermont is not generally a place that is run with idiocy and hype. Its a place where money has little part in politics and people get what they want. Like one of the most livable places on Earth, and one that is leading the way into the future environmentally, socially, etc. It has a fair number of issues too, but here we have a very classic example of how government FOR THE PEOPLE works, vs how government FOR THE BANKS works. Well, heck, even the US Senate isn't totally corrupt yet, heh.
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.
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.
Windows will never really be safe, you have no idea what the heck MS is up to today, and what the next service pack will do. Just install FC23 or whatever and be done with it.
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.
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.
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...
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.
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?
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.
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.
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.
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.
I don't know how that guy managed to make his money, luck basically. He's got the good judgement of a pigeon.
Helium 3 is NOT A VIABLE FUSION FUEL, PERIOD. There is no such thing as Helium 3 fusion power, it simply cannot be viable. Where this idiotic notion of 'Lunar Helium 3' came from I don't know, but people should frigging do a tiny bit of basic research before they blort out this kind of nonsense.
3He fusion requires temperatures on the order of 10 BILLION Kelvins (Celsius), and the reaction rates are so low that the smallest viable reactor size would be on the order of a 100 gigawatt power plant.
Assuming we were able to build a tokamak that was commercially viable (which is unknown) then it would require something like an equally large step to reach 3He-D fusion. Not to mention the need to find the 3He, and Lunar mining would NOT be cheap.
p-B fusion is a MUCH more viable target, maybe not as cute in terms of being aneutronic, but VASTLY easier to achieve. Nobody is going to achieve Helium 3 fusion in this century, that's almost a given.
Exactly. How long will it be before such people start to just vanish into some black hole somewhere. If that doesn't work then their family, friends, etc will likewise suffer. This is always the last resort of the more powerful to the weaker. That's what being weaker MEANS, you can't protect yourself.
And if the tactic does work? It will just become another tool of the scumbags. Turds always float to the surface.
If I could make a mechanical calculator at that scale, then I could just as easily make an electronic one, at that scale. The problem is the "manufacturing issues" they talk about are the same challenges that thwart building microelectronics on the same scale. Solve one, you solve the other, and electrons are a LOT smaller than rods, there's very little chance rods will outperform electronic or electro-optical gates of similar scale.
Well, we have the ability to map a very small number of neurons. Actually do we even have that? We still don't EXACTLY understand how the potentiation of each synaptic junction works. There are something like 700 TRILLION of them in a human brain too, so we're not even remotely close, even assuming we can determine the weight for each one individually, to scanning even a tiny fraction of an actual brain. We couldn't even do that fruit fly, so even assuming we know where the synapses are that's like having just the hardware but not the software. And if you don't know how the things work at some higher level then you're going to actually have to measure the weight of each of those 700 trillion junctions to create a human brain sim. I'm guessing, but I think we're a LOT more than 30 years from being able to do that. Just think of it in terms of being adatabase problem. 700 trillion records? Yeah, good luck! In every respect our capabilities obviously fall far short, and even things like mice, heck even fish, are WAY beyond our reach there. So I think there's a huge amount of basic work that comes before even worrying about actual brain sim itself. At least that's how I see it, and that's STILL assuming that brute sim is a better investment than figuring out the principles and building more abstract models. By the time you get your brute force sim to work I may well be able to implement a more abstract one with 1 millionth of the effort.
But of course we don't know. I agree with you on this, Markram's way will cost a boatload more than EUR 500 million. I'm not so sure its WORTH that boatload, and I would want to know before going down that road at all, at least very far. With simply CNS sims there's almost surely things to be learned, but it is much less clear there's a real value proposition with higher organisms.
I think you are presenting a false analogy at multiple levels here. We might say today that maybe the world progressed faster to steelmaking one way vs another, but AT BEST that's 20/20 hindsight, you can't actually prove it, the analogy shows no particular connection with AI, etc. There was no 'plan' to 'get steelmaking' this is the real world not Civ IV tech trees, and people 1000's of years ago didn't even have a concept of progress as a general thing. Nor is anyone proposing that we halt everything, Markram's project is only one possible way of advance, not the only way, so you've got an excluded middle AND a red herring in there as well! But really, its mostly just a limited analogy. I don't think we can know how good or bad it is right now.
Are we really that much cleverer than cavemen throwing rocks in fires? Maybe, but not cleverer than bronze age metalurgists. In terms of what we know about how brains function who's to say we're much ahead of them at all?
Overall I think we're not in huge disagreement. I think brain simulation WILL continue. I think its likely to be a bit less grandly ambitious than Markram's for a while. I think I'd simulate a C. Elegans CNS first, then maybe a Planaria worm, and then perhaps some higher invertebrates, simple chordates, etc. Its going to be a good solid 30 years before the raw compute power exists to simulate a human brain anyway, maybe longer, so there's not that much of a rush if you ask me.