Wow, this post has some hard core moralizing in it. The whole concept that a mean comment is going to prevent the next AirBnB. That may be the case, but it's unfalsifiable and straight up passing more judgement. I can do without that, personally. I mean, you seriously won't let Linus Torvalds post on HN?
Not only that, but overly positive, glass always half full comments for the sake of guidelines might prevent the next AirBnB too.
Perhaps for those people seeking feedback who want brutally raw, might-hurt-a-bit honesty, a special flag can be set inviting all manner of such comments. I know I'd elect for that, and would be disappointed with anything less. Spicy internet discussion can flush out the pipes of a concept and invigorate thoughtful discussion quite efficiently. It can also derail, but it's worth the risk IMHO.
Same here. I spend nearly all my time in Firefox and Emacs. My main laptop has been a MBPr, but more for the hardware than for OS X per se. Lately I've been trying a 1st gen Chromebook Pixel. So far the experiment is going really well. If that continues I might upgrade to a Chromebook Pixel 2 LS as my new main machine.
Basically I want a Linux laptop that "just works", with MBPr quality (or better) build, screen, and keyboard. One obvious choice is the updated XPS 13. A perhaps less-obvious choice is the Pixel.
Having said all that, Emacs for ChromeOS could have some advantages, e.g. battery life, not needing to "break the security seal" by putting a Chromebook in developer mode, and not needing to chroot (although that's quite easy and ~30 minutes).
I bought it for an excellent user environment for everything but programming, that could alt+tab into a programming environment. All of my non-tmux work is inside a browser. It made sense to me that I would have an environment that rapidly (less than 3 seconds) boots from cold to Chrome with optional Linux environment when I need it. It has advantages of being automatically encrypted and having deep integration with Google Apps that I use every day.
Thank you for your great answer . I am also considering buying Chromebook because my case is almost same as you (everything is inside of chrome or inside of bash ) , but I am a little skeptical about crouton , Do you have(or know) any video for showing/introducing how it works on Chromebook , how multiple tab's in bash works , I know this question is little wired but I haven't seen any crouton on chrome book yet , So I am very curious . Can it replace my ubuntu machine ? ( because I use it just for chrome(web) and heavy terminal usage (bash , gcc , gdb , emacs , etc), and I don't use any gtk qt etc app). Thank you .
As for replacing your ubuntu machine, the default distro is 12.04, but I'm sure you can install the latest.
I don't know about the amount of shell tabs you can have (as I use tmux), but my short experiment seems to hold up well.
The only problems I think you'll face is the scary 'OS Verification' at startup and limited memory (but can be solved by using a SD card). croutons are cheap to install so install, remove, install until you find your niche.
Oh , I think there is a misunderstanding going on here , Maybe I describe it in bad way , By replacing I didn't mean installing ubuntu on chromebook , I just want switch away from this whole gtk/qt/unity/gnome/kde/xfce/cinnamon/mate non-sense.
Main thing I am looking for is how is crosh , when you using it in heavy way (gcc,emacs etc).
You can also install a chroot with the cli-extra target. This launches the chroot in a TTY with the `sudo startcli` command from the crosh shell. Instead of launching into a desktop environment.
Then I just startup a ssh server there. And head back to ChromeOS and SSH to local host (the secure shell plugin is good for this). This means my chroot is totally independent of any chromeos windows or crosh shells.
I run a window manager with a full-screen xterm that has my tmux session. My packages are installed in a chroot that uses either Ubuntu 14.04 or 14.10 (I don't remember exactly, on a different machine right now) using Crouton. This was better for me since I have a non-trivial xmodmaprc that I prefer.
Or to get a really cheap device with long battery life. I've thought about getting one for travelling, since it would be lighter than my Thinkpad and way less annoying if it got lost or stolen, but still has a keyboard and can run many "normal" linux applications.
I want the Chromebook because it's small, inexpensive, and fast for things like checking email. I want Crouton because it gives me Emacs, R, and anything else I want to run on Linux. I bought it in spite of the installed software.
What software? "The browser"?
And do I misread the crouton instructions or is that actually still running the very same thing, same software, in developer mode with chroots for Other Things™?
My laptop died and I am broke and jobless, and needed to do some programming for InstaSource. My only choice was to use my Chromebook. Now I do all my coding on it. It's surprisingly awesome!
I agree with this guy! Computers will never be fast enough to justify the use of a forward thinking library like this! Nevermind future integrations with the GPU or SIMD or technological enhancements we can't even imagine! Why, Javascript is so slow I don't even know why I stopped browsing with wget piped to e-mail like Stallman!
You've exactly proved my point - "future integrations with the GPU/SIMD" - they're not the future - they're now. If you want to leverage them, don't write javascript. Or at least, don't write pure javascript implementations, call down to a C or Fortran implementation - which as I said, are hard enough to tune.
If you do want to write javascript however, why not write something more application based, why does it need to be raw linear algebra? Like an image processing library, or a linear-transforms-for-svg library[0]? Why do you need the raw linear algebra primitives, such as being able to map across elements?
Your snark towards my criticism is also absolutely ridiculous - no offense to the author, I think this is quite cool, but it is in no way "forward thinking". I could link to tens of other javascript linear algebra libraries, so why is this one the best? And more importantly - why should it be shielded from criticism?
[0] I will admit, there is something similar to this, based off this library: https://github.com/mateogianolio/vectorious-plot which slightly detracts from my argument, but also bolsters it - as it proves that this library is only really useful with an application library wrapped around it.
It's useful having some code in JavaScript. Even if its not fast enough for some things, having a nicely organised and documented library can be very useful.
Optimizations, using Typed Arrays, could make the code considerably faster. C++ addon code could make it faster still. Intrinsics within that addon code could use SIMD. While this library certainly is a lot slower than the equivalent C or Fortran, it's got potential, and it's not something that I'd dismiss as being pointless because it's a particular thing that's written in JavaScript.
Also, in the browser, language choices are very limited. Another reason why having JavaScript code that does a variety of things (including vector maths) is useful.
This does not generalize to arbitrary purposes. If you just want to detect that the user has run more jobs than your build system can possibly benefit from and print a warning, there is no reason to start messing with the jobserver. This is not the Ockham solution :)
Why print such a warning? For most projects, make -j65536 will be effectively equivalent to make -j, both of which are perfectly fine. Suppose you're on a system with more CPUs than you have build rules in your build system; you shouldn't print a warning just because someone does make -j$(nproc).
It makes some sense to want to know this. You might know that your build process doesn't benefit from more than 4 jobs, and want to alert this to the developer who tries to use more.
Please avoid such things. Useless warnings just create noise that mask real ones. Just this one may not matter, but the same rationality would apply to hundreds more.
As shown in the post, targets are not always grep-able. The post's makefile contained the target "par-30" even though that string appears nowhere on the page or in the makefile.
You need to write a full parser to discover all the targets.
Running "make -p" is running a full parser which someone else wrote. Grep is not extracting the targets from a makefile there, it's extracting the targets from an intermediate representation of a makefile.
> The real insanity with make is that it has no interface to check whether a Makefile contains a given target.
>
> Best you can do is to run make -n target to probe, but it's possible to write Makefiles that run code even though -n is used, which will defeat such probes at distribution scale. It quickly becomes an exercise in heuristics and output parsing.
The comment I replied to, chaosfactors, specifically specified grepping the makefile. You're arguing that you can find all the targets and I never said you can't. I simply said you can't find them all by only grepping the makefile.
I usually add two targets for my my projects: 'help' and 'showconfig'. 'make help' explains which targets to use and/or how to combine them. 'make showconfig' shows all the important what the important internal vars and common vars (CFLAGS, LDFLAGS, etc) are and their values.
