Show HN: Brewlet – The Missing Menulet for Brew.sh - <AUTHOR> https://github.com/zkokaja/Brewlet <comment><AUTHOR> Hi, I'm the author of this project. I created this because I always found myself unaware of the state of my brew packages (e.g. how many need to updated, what versions are they on, should I update them?), and I had to manually type in some commands.

I decided a simple menulet (or menu bar app) can serve as a minimalistic UI for this simple interaction. With it, I can get a notification when new packages are available or just glance at its icon.

It has the core functionality I want now, but sense that it could still be improved. So, any feedback in terms of UX, ideas, new functionality, etc are welcome.

Thanks!

<comment><USER2> It would be nice if you could actually install it using brew.

<comment><AUTHOR> Thanks for the input. I was planning on doing that, but I read in their documentation that they may reject apps that are "not notable enough" and without enough stars on GitHub[1]. So I'm waiting a bit before actually submitting that pull request.

[1]: [https://github.com/Homebrew/homebrew- cask/blob/master/doc/fa...](https://github.com/Homebrew/homebrew- cask/blob/master/doc/faq/rejected_casks.md)

<comment><USER3> It might be cool to just create a tap for now. Afaik a tap can be as minimal as a git repo with the .rb package definition file, which you will have to write at some point anyways.

<comment><AUTHOR> That's a good idea, thank you.

<comment><USER4> I've added apps I found on the wild before by creating easy enough to do PR/taps, as long as you follow guidelines It can get merged, you can always host your own namespace to not depend on upstream merging anyway I guess.

Great product</comment></comment></comment></comment></comment></comment>


EasyWaking 101 - <AUTHOR> https://easywaker.com/articles

<comment><AUTHOR> Four Points:

1) Be gentle with yourself 2) Be hard on yourself 3) Go to bed on time 4) Look forward to waking up

</comment><comment><USER2> I've used this site before, and it does a great job of getting me up in the morning.</comment>


Y Combinator Challenge #13 - Online Learning - <AUTHOR> http://astartupaday.wordpress.com/2008/08/06/y-combinator-challenge-13-online-learning/ <comment><USER2> I'll add something here, since I'm writing an application focused on language learning: Pick an area to focus on, and provide lots of automation for the user.

Even though my application is _very_ beta, it automates a lot of the drudgery in building studylists, which differentiates my software from all the other spaced repetition systems out there. This has gotten a pretty positive response so far, and has the added advantage of being very difficult to duplicate, giving you a big competitive edge.

Not sure how this could be applied to subjects other than language, and doing it for language is hard enough, but that's what makes this an interesting problem. :)

Also, I've dug around quite a bit, and talked to a few other researchers, and have yet to find any proper studies on the effectiveness of SuperMemo algorithm itself. There are lots of testimonials, but nothing involving a control group, and so until I see some hard data, I'm going to remain a little skeptical.

If anybody knows of such a study (with associated data), please let me know.

Of course, since I'm building a learning system, this puts me in a good position to undertake such an experiment. _grin_ Which I plan to do next semester, using a few hundred students' worth of Japanese classes.

<comment><USER3> Upvote for using hundreds of student hours. Free labor is good for startups!

I also resent the fact that your time is viewed as worthless if you don't have a college degree.

<comment><USER2> It's not even about free labor. The students in the classes will get free access to my learning system, which has all their class materials built-in, and so no matter what the result of the experiment, the people who use the system will at least reap the same level of benefit that they would with traditional flashcards, and with far less work.

So, I'm doing something to help them, and in return, getting some data to improve the system. Truly the epitome of a win-win scenario.

And, actually, I do have a college degree. Two of them, to be precise, and I rather wish they had been printed on toilet paper, so they'd be worth something.

I've met many college-educated idiots, and many self-educated geniuses. I've also met a similar number of fantastically intelligent college graduates, and self-educated morons. The true test of intelligence, in my experience, is action. Those with intelligence act, create, build, and contribute to making humanity _better_ , whether they want to or not.

So, you've been upvoted for being agreeable. :)

</comment></comment></comment><comment><USER4> Having failed a couple papers in educational theory classes for proposing vaguely similar ideas, I'll give you the standard criticism: How does this maximize the child's intrinsic motivation to learn? Which isn't the same question as 'will this be fun,' which you make the case for. But rather, will this make kids the kind of people who want to check out non-fiction books from the library on their own ten years from now.

<comment><USER3> >But rather, will this make kids the kind of people who want to check out non- fiction books from the library on their own ten years from now.

That's a really tall order.

<comment><USER4> While we don't know much about building intrinsic motivation, we do know a lot about the factors that undermine intrinsic motivation. So in practice if you can avoid all these, and you make the process both enjoyable and useful, then at least you're on the right path.

</comment></comment></comment><comment><USER5> nitpick: spacing algorithm does not "dramatically increase memory." Your memory is not so much increased. Your retention rate is what increases.

Another nitpick: 10 minutes a session is too short for anything of any intensity. For single sessions, 40 minutes would be better. But again there isn't a hard rule. Oh well, ideas surely are cheap.

<comment><USER6> Thanks for the correction, I've updated the post accordingly.

The idea behind the 10 minute sessions was to address issues with short attention spans. Maybe that could be another dynamic variable - the lessons change in duration once they reach a point of diminishing returns.</comment></comment>


LibOS – A library operating system for Linux - <AUTHOR> https://lwn.net/Articles/637658/ <comment><USER2> Now this is userspace networking I can get behind!

Rather than re-implement a new network stack and solve all the same problems again, this builds on the years of good work already done and leverages the existing time investment within the existing stack.

"Librarising" existing stacks to userspace, great idea, this is the way of the future.

<comment><USER3> The NetBSD rump kernel (rumpkernel.org) does this for every driver in the kernel, and is part of the OS, so they are maintained (there are lots of stacks pulled out but not maintained).

Thats why it is important that this project becomes part of upstream so it can be maintained as the stack changes.

</comment></comment><comment><USER4> Reminded me of that quote:

"An operating system is a collection of things that don't fit into a language. There shouldn't be one." \--DanIngalls

<comment><USER5> There are environments that do not have a strong distinction between OS and language. While adored by their users, for some reason they are never very popular. Oberon, Smalltalk and the old Lisp Machines come to mind. (Maybe Forth too, though most "Forth OSes" never tried to do multitasking or even file systems.) I suspect there are anti-network effects holding them back. They support one language and one language only. You can't easily bolt them into whatever OS you already use. None of your familiar tools run on them either. Adoption rates are poor with no way to dip your toe into the environment.

What would a "no OS" system that equally supports multiple languages look like?

edit: Multiple languages _that have nothing in common._ Think about the insane variety of languages you have available on *nix.

<comment><USER6> IIRC the Lisp Machines supported C in addition to the system's dialect of Lisp.

<comment><USER7> > IIRC the Lisp Machines supported C in addition to the system's dialect of > Lisp.

IIRC the Lisp Machines (well, CADR at least) compiled code down to some pretty high-level machine code implemented in microcode. How many standard C idioms could actually be expressed in that kind of code?

I'm also not seeing how it would give a speed-up, which is the usual reason to code in C.

Was the C compiled to microcode?

<comment><USER8> No reason you can't compile C down to that. It's just that there will be less of a clear performance advantage for C as some of the semantics will be slightly awkward to map to that instruction set.

You might still get a speedup by writing C in some areas, but I think the real reason for supporting it is that you have a bunch of legacy software and drivers written in C, and it's easier to get a C compiler working on that platform than to port all that software.

</comment></comment></comment></comment></comment><comment><USER9> This is excellent.

Anyone who's ever faced the daunting task of bolting TCP on top of custom datagram protocol can certainly confirm how useful a library like this is.

<comment><USER10> Why isn't that "just" either using lwIP, or using your host's TCP running against a TUN/TAP device and then encapsulating the data you read from /dev/net/tun into your custom datagram protocol?

(This is not meant to be dismissive, just inquisitive. I'm sure it can't be anywhere near as easy as what I said, I'd just like to learn why.)

</comment></comment><comment><USER11> Stupid question: why does the Linux Kernel handle the networking in the first place? Why not implement everything in userspace from the start?

<comment><USER12> For a number of reasons:

\- It used to be impossible to implement securely. Until very recently, there was no hardware support for virtualizing the network buffers, which would mean emulating the network hardware in userspace. This would be very slow.

\- Because even today, many devices don't have the required hardware virtualization support. For example, many (most?) ARM devices. If you give direct DMA access, you might be allowing anyone to splatter whatever code they want across whatever memory they want.

\- Without kernel arbitration of some sort, there's no way to do load balancing across services, throttle, or firewall effectively.

\- The kernel is designed to provide a uniform interface for all programs to the hardware. Putting networking in userspace gets rid of this abstraction, and means that every program has to be aware of the network hardware; software that works with file descriptors directly can't use the same abstraction for files and network.

\- Because there are no hardware limitations on the amount of multiplexing. I don't remember how much muxing various hardware supports, but hardware has limits for this sort of thing. If you want more than N processes using the virtual network, you might be SOL with a virtualized userspace network stack.

<comment><USER13> These are valid objections to _in-process_ access to the networking hardware. Not to running the networking stack in user space, in a privileged process.

For the latter, performance concerns would be a bigger issue.

</comment></comment></comment><comment><USER14> It will be interesting to see how this evolves; hopefully it will make it easier to build a userland TCP/IP stack, and maybe even to make it easier to ship a new transport protocol (this might make it easier to push for HTTP over SCTP instead of TCP, which makes far more sense, really). Also this will be nice if it allows userland applications to utilize ICMP (traceroute/nmap would no longer be nerfed without root access). NUSE alone should be incredibly handy.

<comment><USER3> You still need root access to connect to an outside network interface from the userland stack, eg a raw socket...

Linux has unpriveleged icmp sockets but no one has ever used them apparently - IPPROTO_ICMP eg see [1]

[1] [http://stackoverflow.com/questions/14018584/python-with- unpr...](http://stackoverflow.com/questions/14018584/python-with-unprivileged- ping-in-linux-ipproto-icmp)

</comment></comment><comment><USER15> Uh, not sure what's up with lkml.org -- I see some G+ +1 buttons but no actual text, in both Firefox and Chrome. Presumably the article is this:

[https://lwn.net/Articles/637658/](https://lwn.net/Articles/637658/)

in which case it sounds awesome!

<comment><USER16> Thanks, we updated the link.

</comment></comment><comment><USER17> My first thought was that this sounds like an idea taken from microkernels. Is this a correct analogy? Would it be sufficient to use libos and fuse to call the Linux kernel a microkernel? What would be missing?

<comment><USER18> For one, the _micro_ kernel would be missing ;)

More seriously though, you're absolutely right in that it's a step in the direction of an "optional" microkernel architecture. That's actually how rump kernels on NetBSD started: running the kernel file system driver as a library in userspace on top of a FUSE-like subsystem. It's pretty useful functionality, since it allows you to handle untrusted file system images safely in userspace, while not imposing performance penalty on the trusted images which can be handled by the same driver running in the kernel. Unlike with FUSE-specific drivers, you don't run into issues with unsymmetric driver support in userspace vs. kernel.

</comment></comment><comment><USER19> How might this relate to rump kernels and unikernels?

<comment><USER3> The design is quite heavily influenced by the rump kernel design, although Linux has its own issues that make it a bit different. Obviously its only the network stack.

</comment></comment><comment><USER20> I have to credit this blog for much of the material I've absorbed over the years, it's been fantastic how much I've learned here.

I've always managed to learn something new from articles, all this to say that today is different... I really do not understand this library at all.

Could someone explain me different possible uses for this library? What would be the uses of this out of the box?

<comment><USER21> You have a very peculiar comment history - [https://news.ycombinator.com/threads?id=agashka](https://news.ycombinator.com/threads?id=agashka)

<comment><USER20> thanks for bringing that up! Adobe air, bitcoins, and signals. I still don't really get signals, but I'd like to understand this library lol

<comment><USER21> Why are you thanking me?

</comment></comment></comment></comment><comment><USER22> I'm aware of Freescale's USDPAA that runs network stack in user space to achieve wire-speed.

</comment><comment><USER23> The author forgot to add a license for this project. What shall we assume?

<comment><USER24> It was submitted as a patch series to the Linux kernel mailing list, with proper "Signed-off-by" headers in the commit messages. So presumably it's usable under GPLv2.

EDIT: I was referring to the kernel support, but it looks like you might have been talking about the code on Github which uses the LibOS API. That does indeed seem to be missing a license.

<comment><USER25> Do you mean [https://github.com/libos-nuse/net-next- nuse](https://github.com/libos-nuse/net-next-nuse)? There's a COPYING file:

[https://github.com/libos-nuse/net-next- nuse/blob/nuse/COPYIN...](https://github.com/libos-nuse/net-next- nuse/blob/nuse/COPYING) (GPLv2, taken from the kernel)

<comment><USER24> I was talking about the repository linked from the original mailing list post: [https://github.com/libos-nuse/linux-libos-tools](https://github.com/libos- nuse/linux-libos-tools)

</comment></comment></comment></comment><comment><USER26> Does this mean we get to link the kernel as a shared library?

<comment><USER10> If you want that, there's always OSv:

[https://github.com/cloudius-systems/osv](https://github.com/cloudius- systems/osv)

</comment></comment><comment><USER27> Lennart Poettering would do well to pay attention to people like this, continuing to honor the POSIX way.

<comment><USER28> Sorry but that comment is just BS.

<comment><USER27> why?</comment></comment></comment>


"Snowden": Official Trailer - <AUTHOR> https://www.youtube.com/watch?v=QlSAiI3xMh4 <comment><USER2> The hype is real!

The rubik's cube trick is already so good (e.g.: hiding an SD card in a rubik's cube, giving it to a security guard before a security check and taking it back after)</comment>


College Stash - 200+ Free online resources curated for college students - <AUTHOR> http://collegestash.info <comment><AUTHOR> Hello there, with great delight I like to introduce you all to our latest product CollegeStash.info. If you're a student and not sure how to reach that extra mile when in college, collegestash.info would be a great recommendation. We have curated 200+ awesome tools and all of them are FREE. Increase your productivity at every stage of student life from test preparation, finding the right college, scholarship, academic research, finding a job and more. We do not like to stop here, we will be collaborating with our users and will be curating more cool resources as the time goes along.

Once again, we are delighted to welcome you all to check out CollegeStash.info and your will feedback will be much appreciated. If you like the work, give us a vote. Thanks all for you support.

</comment><comment><USER2> This is what I needed in University! Awesome collection, very well done. I am also trying to help college students with one resource in particular - housing. That's why friends and I made www.padpiper.com :)

<comment><AUTHOR> @theLaunchPad Thank you. I found padpiper.com is a very useful resource, congratulations!</comment></comment>


Yale's Ex-President Heads West To Become CEO Of Coursera - <AUTHOR> http://www.forbes.com/sites/georgeanders/2014/03/24/yales-ex-president-heads-west-to-become-ceo-of-coursera/

<comment><USER2> I find this to be an extremely surprising move. I'm not sure why a company like Coursera which aims (or should be aiming) to disrupt the existing structure of post-secondary education in the United States has chosen a leader who is clearly associated with the "old guard."</comment>


Visualization of Wind and Solar power generation in Europe (almost realtime) - <AUTHOR> http://mylly.hopto.me/windineurope/ <comment><AUTHOR> Be gentle: "This system, written in Python, running on a Raspberry Pi under Raspbian"</comment>


Ask HN: Resources for learning advanced JavaScript and React - <AUTHOR> What are the best resources for learn advanced js/es6/react ?
Something similar to "Practical Object-Oriented Design in Ruby"
Right now I'm a junior/mid js developer, but I want improve my skills/code/tests etc...
Any help is welcome. <comment><USER2> I'm always surprised that reading source code is such a rare occurrence or suggestion in this world. If you consider yourself even in the vicinity of "advanced", I think you're capable of learning great stuff by looking at anything on github. Something big, but well organized. Lo-dash, Node, Mocha, etc.

Of course you won't understand everything on first read. But you will learn really good things if you know how to look at something confusing and identify what it is you don't understand; then you can go find didactic materials to fill in the gaps.

This is an amazing way to learn. You get to see how some of the most used, or cutting-edge tools are implemented (for free!). You learn about the tools themselves and thus gain expertise in them. And, you gain the meta-skill of working in unfamiliar territory, which I think is a fundamental key to being considered "advanced".

<comment><USER3> I question the utility of this.

I don't break apart an engine to figure out how to use it, I read the manual about inputs and outputs.

<comment><USER2> Totally fine, so long as you know that makes you an "advanced user".

I can't imagine you'll find a sane place to work where senior people are only capable of learning something after consuming a tutorial or a manual. The nature of the work is to drill down one layer below what you're working on. Do you need to know how to smelt steel in order to be a good car mechanic? No, of course not, but it sure helps to have taken an engine apart. And if you're trying to build the next, better engine, it's really great to see the internals (and the commented motivations!) of previous implementations.

</comment></comment></comment><comment><USER4> Kyle Simpson and the "You Don't Know JS" series. Can't speak highly enough about them.

Also he has a good recent book on Functional Programming, which if you plan on tackling Redux later will be helpful.

I got the physical editions because that's how I prefer books (easier to note / annotate), but all the books mentioned here are available free online / on Simpson's Github.

<comment><AUTHOR> Already read them...very useful but I was wondering if there was something similar for react.

</comment></comment><comment><USER5> The Road to learn React [0] is an open source book that gets continuously improved because it was self-published and the community contributes as well. You will build a React.js application along the way and transition smoothly from JavaScript ES5 to JavaScript ES6. It teaches the fundamentals of React without any tooling or Redux. Afterward, you are ready to go to build your own React applications. I would love to get your feedback on the book! :)

Otherwise, I can recommend to checkout this repository [1] by Mark Erikson to find out more about React and its ecosystem. I am sure you will find plenty of starter tutorials to get into learning React.

\- [0] [https://www.robinwieruch.de/the-road-to-learn- react/](https://www.robinwieruch.de/the-road-to-learn-react/)

\- [1] [https://github.com/markerikson/react-redux- links](https://github.com/markerikson/react-redux-links)

<comment><USER6> I strongly recommend "the Road to react" book to learn react.

</comment></comment><comment><USER7> [https://egghead.io](https://egghead.io) has excellent ES6 React, Redux tutorial videos, and step by step code examples.

<comment><USER8> Worth noting this is the site Dan Abramov, creator of Redux and React maintainer, posts his tutorials on.

</comment></comment><comment><USER9> Gotcha covered.

I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at [https://github.com/markerikson/react-redux- links](https://github.com/markerikson/react-redux-links) . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics. It includes links for learning core Javascript (ES5), modern Javascript (ES6+), React, Redux, and much more.

In addition, my "Practical Redux" tutorial series ( [http://blog.isquaredsoftware.com/series/practical- redux](http://blog.isquaredsoftware.com/series/practical-redux)) shows how to use a variety of intermediate to advanced React and Redux techniques in the context of a sample app, and my "Idiomatic Redux" series ([http://blog.isquaredsoftware.com/series/idiomatic- redux](http://blog.isquaredsoftware.com/series/idiomatic-redux) ) discusses important aspects of good Redux usage, including why common patterns exist.

Finally, the Reactiflux chat channels on Discord are a great place to hang out, ask questions, and learn. The invite link is at [https://www.reactiflux.com](https://www.reactiflux.com) .

<comment><USER10> I know these are great resources, but I don't think redux should be taught with react. Most of the React projects I've seen using Redux didn't need it - all they needed was for their developers to have a deeper understanding of how React handles state.

Learn React first. When you have complex data management problems, consider learning Redux, but master Reacts own state management first.

<comment><USER9> Trust me, I agree. In fact, my standard copy-paste "advice on learning React" includes:

> Definitely don't over-complicate the learning process by trying to learn > many different things at once. Some people will say you should use a > "boilerplate" to learn React, and they're wrong - boilerplate projects > almost always come with too many pieces configured, and are confusing for > beginners.

> Instead, the best advice is to focus on learning React itself first. Once > you have a good understanding of how React works, you will better appreciate > why a state management library like Redux can be useful, and you can learn > about other tools later.

That said, my rough estimates are that around 55-60% of React apps are using Redux, and it's also frequently used with Angular, Ember, and Vue, albeit sometimes in different forms (ngrx/store, vuex, etc). So, while I totally agree that most people should not try to learn Redux right away, it _is_ a very relevant topic to cover.

</comment></comment></comment><comment><USER11> If you truly want to grok JavaScript, I can recommend no better tutorial than this: [https://johnresig.com/apps/learn/](https://johnresig.com/apps/learn/)

It is how I finally grokked JS and it is the same tutorial that I put all new additions to my team through...

</comment><comment><USER12> I'll throw in Brian Lonsdorf's "Professor Frisby's Mostly Adequate Guide to Functional Programming"

[https://drboolean.gitbooks.io/mostly-adequate- guide/content/](https://drboolean.gitbooks.io/mostly-adequate-guide/content/)

And the related video series on Egghead (which I think requires a subscription)

[https://egghead.io/courses/professor-frisby-introduces- compo...](https://egghead.io/courses/professor-frisby-introduces-composable- functional-javascript)

Which reminds me, if you can get an employer to pay for an Egghead subscription and/or a Frontend Masters subscription as part of a training budget, both are great. Also probably worth buying on your own if work won't cover it.

</comment><comment><USER13> We're building an interactive coding screencast tool (called Scrimba) to help people with teaching and learning stuff like JS and React.

A dedicated section for React can be found here: [https://scrimba.com/topic- react](https://scrimba.com/topic-react)

And here is a playlist which takes you through building your first React app: [https://scrimba.com/playlist/playlist-1](https://scrimba.com/playlist/playlist-1)

It's based upon an article I wrote here: [https://scrimba.com/playlist/playlist-1](https://scrimba.com/playlist/playlist-1)

It's all free. Hope it helps!

</comment><comment><USER14> I'm improving my JS skills by learning how to read and understand the source code of mithril.js.org (I'm doing write ups at: [https://gist.github.com/CarlMungazi](https://gist.github.com/CarlMungazi)).

It's what we use internally at work so it made sense for me to actually understand how it uses JS to tackle all the problems a framework is supposed to solve. I've only been doing it a short while but I've learnt a ton already.

I casually glanced at the source for Ember and React over the weekend and I could understand much better what was going on because I had a reference point based upon the source as opposed to just knowing the APIs.

</comment><comment><USER15> Stephen grider's udemy courses on react (all 3-4 of them are great). Totally recommended.

<comment><USER16> I'm working my way through these and love them. I'd bought books and followed tutorials so I'd completed 3-4 "hello world" apps. With Stephen's videos, I thought, "oh, great, another hello world" but the way he explains things, sudden I _understand_ what it all actually meant instead of just bashing together code and hoping it worked.

</comment></comment><comment><USER17> Here is an interactive map for learning Javascript :

[https://learn-anything.xyz/programming/programming- languages...](https://learn-anything.xyz/programming/programming- languages/javascript)

And here is one for learning React :

[https://learn-anything.xyz/web-development/javascript- librar...](https://learn-anything.xyz/web-development/javascript- libraries/react)

Both maps are community curated so if anyone thinks there is a more efficient path for learning them, you can submit pull requests. :)

</comment><comment><USER18> I would say pair programming with others and reading code as a group together is the best way to level up. While reading open source projects will fill in some knowledge gaps and teach you to write cleaner code. You may miss the subtle aspects that makes the code one step better then others. When I pair program with seniors I get to see how they come at a problem, make design decisions, and find out why they do something some way. Pairing with a less senior developer causes you to reflect on yourself. If you can't explain something to someone else in simple terms then you might need to revisit that idea. Also a good way to remind yourself how much you have grown as a developer, and how much farther you still need to go. Pair programming in a group is a great for a team to understand how each other thinks. It also confirms styling techniques for the code base and also allows people to fill in random knowledge gaps they may not know they have. Finally it has been proven over and over again the more a team communicates with one another the better they work as a team even though our codes and docs suppose to be the best way to convey our thoughts to other programmers. Spending some time every day talking and working together is the fastest path to bring entry level and junior level developers to a senior level.

</comment><comment><USER19> I have a free advanced (and beginner) daily email course to help you learn React: [https://nanohop.com/react-daily-emails/](https://nanohop.com/react- daily-emails/)

The idea is to get a small dose of React every day.

I'm also always looking for what else to include in the course - so I'd love to hear what you find most difficult, or what you think is lacking from current learning resources.

</comment><comment><USER20> React-Redux complements React in some great ways. It has been my state storage of choice from the beginning. IMO, it would be better to start react with it rather than changing habits later. The go-to tutorial series is here: [https://egghead.io/courses/getting-started-with- redux](https://egghead.io/courses/getting-started-with-redux)

And definitely use typescript if you value good code quality (and your sanity). The advanced type system and compile time type checking is really a boon to the JS ecosystem. [https://www.typescriptlang.org](https://www.typescriptlang.org)

You'd like to get comfortable with the latest tools that compile, transpile and pack the code for you (you might be familiar with that already.) Here might be a good start: [https://medium.com/@fay_jai/getting-started-with- reactjs-typ...](https://medium.com/@fay_jai/getting-started-with-reactjs- typescript-and-webpack-95dcaa0ed33c)

Have fun!

<comment><AUTHOR> Typescript works fine even with all the libs written in js/es6 from npm ?

<comment><USER20> Most popular libraries these days either include their own typescript definitions, or the definitions are available vie @types (it is as easy as npm install --save-dev @types/library-name)

If on the off chance that no typings are available, you just write a simple namespace declaration (usually a one liner) and start using the library right away, albeit without smart code sensing / completion. See [https://stackoverflow.com/questions/22842389/how-to- import-a...](https://stackoverflow.com/questions/22842389/how-to-import-a-js- library-without-definition-file-in-typescript-file)

</comment></comment></comment><comment><USER21> React is full of declarative code. Something I'd recommend whole-heartedly is Michael Fogus' Functional Javascript book. It shares a lot in common with POODR in that it's conscious of _why_ functional techniques are useful and how to think in a data-oriented way. The book is self-aware of the beginner's mindset in absorbing that information and is very well-layered.

Personally, I feel the best way to learn is by experience and by exposure. By seeing similar code in different contexts, you can learn why React programs tend to rely on certain patterns. To that end, working through something like How To Design Worlds ([http://world.cs.brown.edu/1/](http://world.cs.brown.edu/1/)) or the Elm guide ([https://guide.elm-lang.org/](https://guide.elm-lang.org/)) will give you points of comparison that will help you better articulate what you decide to do in React.

<comment><USER21> [http://eloquentjavascript.net/](http://eloquentjavascript.net/) is another fantastic book in the same vein (and free!).

</comment></comment><comment><USER22> If you want to get good at JavaScript, do learn about closures and lexical scope. Example assignment: Make a function that loads a list of images and then show the average width of the images. Then make three versions of the function, one that loads the images in serial, one that loads the images in parallel and one that loads max three images at a time.

</comment><comment><USER23> A number of people have mentioned Dan Abramov's Redux tutorials on Egghead, which I recently went through and got a lot out of. As a supplement/alternative I also found this series of LearnCode tutorials ([https://www.youtube.com/watch?v=1w-oQ-i1XB8&index=1&list=PLo...](https://www.youtube.com/watch?v=1w-oQ-i1XB8&index=1&list=PLoYCgNOIyGADILc3iUJzygCqC8Tt3bRXt)) to be really useful and informative. Where Abramov's series was great for seeing how to start with the most simple integration of Redux and building up to an advanced one, these start out advanced, allowing it to cover a few more topics (like middleware). Just figured I'd throw that in.

</comment><comment><USER24> I've really enjoyed these courses but they aren't free (work pays for me) [https://tylermcginnis.com/courses/](https://tylermcginnis.com/courses/)

</comment><comment><USER25> React patterns, techniques, tips and tricks [https://github.com/vasanthk/react-bits](https://github.com/vasanthk/react- bits)

</comment><comment><USER26> I need to remind myself to read these more often.

[http://shop.oreilly.com/product/9780596517748.do](http://shop.oreilly.com/product/9780596517748.do)

[http://2ality.com/](http://2ality.com/)

Very useful day-to-day and first place I go:

[https://developer.mozilla.org/en- US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Reference)

</comment><comment><USER27> Shameless plug: I did a free open source video series called "Building products with javascript" [1] that covers building CRUD webapp using javascript (including es6+), node, express, react, redux, rxjs and all that kind of stuff. Will be happy to answer any questions :)

[1] [https://github.com/yamalight/building-products-with- js](https://github.com/yamalight/building-products-with-js)

</comment><comment><USER28> Mostly pre-es6, but this is my favorite "intermediate -> advanced" JavaScript book: [https://www.amazon.com/Effective-JavaScript-Specific- Softwar...](https://www.amazon.com/Effective-JavaScript-Specific-Software- Development/dp/0321812182)

There are gaps/things that have changed since the book came out, but this is a really great resource for understanding the core JS language.

</comment><comment><USER29> [http://testdriven.io/](http://testdriven.io/) is meant for the advanced beginner

</comment><comment><USER30> I just spoke @ JSChannel 2017 & published a book on this very topic ([https://github.com/FarhadG/ui-react](https://github.com/FarhadG/ui-react)). It has reached the weekly best seller's list, so I hope it can be of some use for your goals.

</comment><comment><USER31> [http://www.seas.upenn.edu/~cis197/](http://www.seas.upenn.edu/~cis197/)

This course (offered at my University) has some good material on React, not to mention the fact that you can even download the starter code for the assignments and work through it.

</comment><comment><USER32> We have 56 videos and counting on React / ES6 with lots of free videos in the collection. Feel free to take a look

[https://www.codemy.net/channels/react- foundation](https://www.codemy.net/channels/react-foundation)

</comment><comment><USER33> Matt Greer has been doing a blog series on react internals.

[http://www.mattgreer.org/articles/react-internals-part- one-b...](http://www.mattgreer.org/articles/react-internals-part-one-basic- rendering/)

</comment><comment><USER34> Not free, but Brian Holt (LinkedIn/Netflix) has a great series on Frontend Masters: [https://frontendmasters.com/courses/react/](https://frontendmasters.com/courses/react/)

</comment><comment><USER35> React Native Template Design [http://www.9lessons.info/2017/03/getting- started-with-react-...](http://www.9lessons.info/2017/03/getting-started-with- react-native.html)

</comment><comment><USER36> Commenting to follow this thread. And if I may add a question: Are there such things as javascript tutoring services?

</comment><comment><USER37> It seems everyone is recommending books/courses/similar. I'll go the other way around. This is difficult for me to say, but I think I am an expert in CSS+JS. I know the inner workings and really advanced things of CSS, and while JS API is quite broader I know some in-depth JS APIs that your average developer doesn't even know exists.

I got to this point first in CSS and then with JS by making side projects and focus each one on a different advanced concept. I will also say it in 1st person as I experienced it as it might sound insulting otherwise:

\- __Don 't get attached to my code __. My code is crap. My 6+ months old code is a lot more crap. Always think ways of improving it. Sidenote: try to make it as standard of possible. Initially I did things _my way_ until my open source started to get some traction and it was a mess.

\- Once I got past the basics and mid-level, what I did to keep up learning was to try to focus each small side project around a technology I wanted to learn in-depth. Examples: Umbrella JS[1] is about a modular codebase, Superdom [2] is about Proxy, drive-db [3] is about talking with external APIs and DB design, etc.

\- Push the limits on the technology on each project. Don't just do the basics and call it a day, try to find what is possible and what is not. Examples: Umbrella JS'[1] performance is similar to jQuery thanks to using the prototype properly, Superdom's [2] Proxies are recursive-ly, drive-db [3] is cached for maximum performance, etc.

\- If I don't use it no one will. Publish it for feedback after it is polished from feedback from different projects. Focus on the positive comments to keep going and on the negative ones to keep improving. Because I know my code is crap, when someone says X is quite bad I agree on principle and find a way to fix it or prove to myself that it _was_ the right approach. Examples: Umbrella JS initial code wasn't good for the different ways of importing it, so I added a UMD-ish kind of thing. Superdom was really buggy so I had to write a few tests all around it. drive-db was not good for promises-based code so I converted it to ES7.

There is something I haven't made which I am trying now that it's reading and understanding large, public projects such as Ghost. I have done something similar while contracting, but those closed-source project's code is IMHO generally messier and you are normally trying to go for business requirements, not really focusing on pleasure/learning so much.

[1] [https://umbrellajs.com/](https://umbrellajs.com/)

[2] [https://superdom.site/](https://superdom.site/)

[3] [https://github.com/franciscop/drive- db](https://github.com/franciscop/drive-db)</comment>


The Future of Graphics Programming: The Vulkan API - <AUTHOR> http://home.seekscale.com/blog/the-future-of-graphics-programming-the-vulkan-api <comment><USER2> Timeless Graphics API-related rant: [1]

1: [http://programmers.stackexchange.com/a/88055/4994](http://programmers.stackexchange.com/a/88055/4994)

<comment><USER3> Timeless rant? It's more like a history lesson, which is the direct opposite of "timeless".

Nevertheless, thanks for the link, this was incredibly informative and well- written.

</comment></comment><comment><USER4> I think this has a good chance of vastly improving the graphics driver situation on Linux. Providing Vulkan support should be a lot less work than providing a full OpenGL driver, and an OpenGL library can probably be written on top of that.

<comment><USER5> Was thinking the same. With Vulkan providing a low-level API, now someone can write a cross-platform OpenGL implementation, and most of the pain people have suffered from crappy GL implementations and their differences can go away.

Of course, OpenGL may still be bloated and slow, but at least _consistently_ so.

</comment></comment><comment><USER6> Was it just me or was reading that LIGHT GRAY text on white background hard ??

<comment><USER7> No, it is not just you. It is hard to read for me too. I highlighted the text to make it easier to read it.

</comment></comment><comment><USER8> I wonder how relevant Vulkan is going to be with Apple replacing OpenGL with Metal, Microsoft on DX12, Sony with GNMX, Nintendo with GX2.

Currently I see it only mattering on Android (if Google cares about it) and GNU/Linux.

<comment><USER5> Apple has Metal and MS has DX12, but Apple, Microsoft, Google and others all have Vulkan. Like OpenGL, portability will be its strength.

<comment><USER9> Citation for Apple? After the last WWDC the situation for any other API on Mac/iOS seems hopeless. And no, that logo on a slide doesn't say much.

<comment><USER8> I watched all the relevant WWDC Metal talks and they look pretty serious to use it as their only graphics API, with OpenGL left in its current state for backwards compatibility.

Unless Apple proves me wrong by adding Vulkan support, I would say they were on the meetings more to learn how to improve Metal than anything else.

<comment><USER10> Would it be feasible to implement Vulkan atop Metal as a library without horrible performance? (Keeping in mind that the baseline of Apple's OpenGL is already fairly slow and behind the times. And Apple's customers already have fairly low expectations wrt gaming/etc.)

</comment></comment></comment></comment></comment><comment><USER11> Will there be an OpenGL compatibility layer on top of Vulkan? Otherwise, GPU vendors will have to maintain OpenGL for backwards compatibility for a very long time?

<comment><USER12> I think this is an interesting point - in theory I guess it's possible that some kind of library or framework could implement OpenGL on top of Vulkan. It would be a bit like writing a graphics driver in user code, and it could have advantages: Vulkan should have more predictable performance, so OpenGL-on- Vulkan should have more predictable performance too compared to the black box driver with mystery performance pitfalls. It would be far easier to debug and profile for performance issues, and easy to gracefully fall back to normal OpenGL calls where Vulkan isn't supported (just forward the calls to the driver's OpenGL).

Still, I'm not sure who would develop such a framework. It could be a new backend for ANGLE (the framework browsers use to implement OpenGL on top of Direct3D). It might also be too difficult - the whole point of Vulkan is to avoid GPU drivers having to have vast, complex, buggy and slow OpenGL compatibility layers, and OpenGL-on-Vulkan may end up just reimplementing the same thing with the same pitfalls.

</comment></comment><comment><USER13> So, Vulkan on Linux, Direct3D on Windows, Metal on OSX, whatever the consoles use... and WebGL(which is OpenGL-ESish).

Are we back to the Glide days?

<comment><USER8> We never left them.

Contrary to urban myths, game consoles never used OpenGL as such, only GL like APIs (the PS3 PSGL wasn't really used).

Apple also only adopted OpenGL on MacOS X due to NeXTStep, before it used QuickDraw 3D.

</comment></comment><comment> T-zex > Vulkan API is more low-level than OpenGL (programmer is responsible for > memory and threads management for example), what triggered this decision?

Surely you have to do this with OpenGL as well.

<comment><USER14> Sure, but with OpenGL's state system you could only safely use it from a single thread. Even if you had multiple threads using it, you still needed a command buffer to safely operate it from one thread processing the commands on the command buffer. Vulkan is capable of being fed commands directly from multiple threads.

</comment></comment><comment><USER15> What is the story with Apple and Sony? Will they support Vulkan?

</comment><comment><USER16> Why is Vulkan needed? Not that I'm familiar with the industry, but I haven't seen a lot of complaints about OpenGL.

<comment><USER17> A really bad analogy (still gets the message across):

If GPU APIs were programming languages OpenGL would be Visual Basic. You're shielded from 90% of the more difficult aspects of accessing the GPU, for a performance cost. Vulkan would be akin to C.

For example: if you use OpenGL the GPU driver will tons of things (costing performance) to make sure that you don't update a texture while the GPU is using it - even if you know what you are doing (e.g. updating a _portion_ of the texture that isn't being used for the render). Vulkan will get right out of your way and let you do what you want: even update a texture while its in use and potentially cause a bug/driver crash or other issues.

The interviewer made this assumption in the second question:

> Vulkan will "replace" OpenGL

Which given my above explanation you will see is probably not true. OpenGL is incredibly valuable because it's so simple - Vulkan and OpenGL simply don't compete with each other, they solve slightly different problems.

</comment></comment><comment><USER18> This is good news. Simplification will help across the board. Also, open source graphics card and middleware projects might benefit from the simplification of lower layers.

</comment><comment><USER19> Ok... "the industry" thinks that we need a new, completely incompatible, standard for graphics development that is locked down (no mention of open source or free software) and that lower level of abstraction will make it more reliable (that is some major PR-bullshit)...

This can, as I see it, only lead to giving more power to the big companies and shafting the indie developers and linux gamers... So in general, fuck those people!

<comment><USER20> The Vulkan SDK will be open source when it is released.

[http://www.gdcvault.com/play/1022018/](http://www.gdcvault.com/play/1022018/)

This is being spearheaded by Valve so the idea that they want to do anything to harm indie developers or linux gamers is simply incorrect.

<comment><USER21> This is orthogonal to availability of open source Vulkan GPU drivers though.

<comment><USER22> Well Valve paid someone to write an open source Linux Intel Vulkan driver.

        - The day The Khronos Group releases the Vulkan specifications is when they plan to open-source their Intel Linux driver.

[http://www.phoronix.com/scan.php?page=news_item&px=LunarG- Vu...](http://www.phoronix.com/scan.php?page=news_item&px=LunarG-Vulkan-AMA)</comment></comment></comment></comment>


Western Digital Demos SD Card with PCIe X1 Interface, 880 MB/s Read Speed - <AUTHOR> https://www.anandtech.com/show/12487/western-digital-displays-sd-card-with-pcie-interface?utm_source=twitter&utm_medium=social <comment><USER2> Is there a security story for this interface? Internal NVMe devices are generally trusted and not passed around, but plugging untrusted things directly into the PCIe bus, with coherent access to memory, is a potentially huge security hole. This was an issue with early Thunderbolt.

And this isn't very hypothetical: aside from passing cards around, counterfeit SD cards are extremely common on Amazon.

<comment><USER3> IOMMUs can protect the RAM if configured to do so by the OS, udevd rules could let you opt-in to to the kernel using the devices - you wouldn't want your network connections hijacked through some plugged-in and auto-detected network device!

But I don't know what the PCIe security model is wrt. to accessing other devices, such as the HDDs.

<comment><USER4> > But I don't know what the PCIe security model is wrt. to accessing other > devices, such as the HDDs.

Should also be protected by the MMU for the most part. You might be able to forge interrupts from other devices though. PCI-E message signaled interrupts are just another memory write to a special part of address space, that unfortunately isn't separated by device at page granularity AFAIR.

</comment></comment></comment><comment><USER5> Ideally one day videomakers will join the audio world in always just recording uncompressed. No longer would you have to think about whether you used the right codec for your editor. It's taking a long time to get cheap because the bandwidth of video is so many times more than other uses. Most people already are way overserved by the standards already in place.

For what it's worth the CompactFlash Association recently ratified CFexpress ([https://en.wikipedia.org/wiki/CFexpress](https://en.wikipedia.org/wiki/CFexpress)) which uses NVMe and two lanes of PCIe 3.0, for 1.97 GB/sec. If my calculations are correct, that's enough for 10-bit 4K RAW at 178 frames per second.

<comment><USER6> Or wouldn't it be better if the compression is lossless.

Lossless, fast Codec that is Open Source and Patents Free. We have FLAC for Audio. ( I dont know why I dont like the name FLAC though ), hopefully we will have something similar for Video.

</comment></comment><comment><USER7> This would be great for DSLRs if integrated especially those who are shooting wildlife at high speed. Contrary to my own previous belief, I thought I would need a smaller hard drive in terms of storage space when I have a larger or faster SD card, but the opposite is true. The faster and bigger the SD card is the more photos I ended up shooting with more duplicates and the more of a need for a home NAS or bigger hard drive.. I think the issue is I never considered SD card as permanent storage media and I would always create a copy of it somewhere else.

<comment><USER8> What you need is more aggressive culling. Eventually more storage space becomes a black hole for a photographer. Your photos go in- and never come out, because the _sheer quantity_ is oppressive. Who wants to spend a Sunday flipping through a thousand tiny variants of the same picture?

If you are a talented professional who takes terabytes of unique & engaging photos, disregard- but otherwise, as another photographer, let me suggest you focus on culling instead of storage.

(Photo Mechanic was a godsend for culling; it's fast as blazes even on weak hardware, and cheaper than a new processor or more DRAM)

<comment><USER9> Yes, cull aggressively. Even talented amateur photogs that I know does not not have more than 10% keeper rate, at max, and that probably include a bunch of meh stuff too. No reason to keep the other 90% with half-nailed focus or unflattering facial expressions. For many years I kept mostly everything thinking that I one day might go back and re-evaluate a photo. That day has so far never happened in 16 years of shooting digital.

<comment><USER10> Yup, if I'm hitting 5/100 I'm having a pretty good day.

</comment></comment></comment></comment><comment><USER11> This is huge! I have no affiliation, but I'm really excited about this. Looking through the comments, I don't think everyone appreciates the implications:

\- It would mean a sane standard for SDcards; none of the ever-evolving, always-limited, SDcard protocol

\- NVMe drivers are already there in any modern OS

\- NVMe is a pretty fantastically wonderful protocol compared to _all_ other mainstream storage protocols (SCSI, ATA, FC, etc). It has low overhead and supports ridiculous amounts of parallelism.

\- This would open up uses of SDcards that aren't really possible today (basically allow for the SDcard to be a general SSD, faster than most (all?) existing SATA SSD).

</comment><comment><USER12> What about IOPS? Assuming IOPS are decent, you could probably replace a SATA SSD with this. This seems like it is in the "middle" ground between a full blown PCIe Gen3 x4 NVME drive and a cheap SATA SSD.

<comment><USER13> A SATA SSD consumes 1 to 5 watts during heavy write activity. That's hardly worth mentioning for a 2.5" drive in a desktop enclosure, but it's a big problem for an SD card with no way to get rid of the heat!

<comment><USER14> Phone LEDs which put out 1W in a much smaller package somehow survive.

<comment><USER13> A 1W LED is soldered to big heatsinking planes on the PCB it's mounted to, which is itself designed to sink heat away into the phone body. An SD card is wrapped in plastic, slides into a plastic slot, and touches the phone with only a few small pins.

Plus an LED behind a lens and cover on a phone or inside a flashlight is perfectly fine to run at 60C, but eject an SD card at 60C into your hand and you'll be throwing it across the room.

<comment><USER15> > but eject an SD card at 60C into your hand and you'll be throwing it across > the room.

Probably not, given the very low heat capacity of an SD card's plastic casing. But I can say from experience that ejecting a 2.5" SATA drive with a metal case that's well over 60°C will cause you to drop it quickly. It's a good thing SSDs can handle falls without trouble.

</comment></comment></comment></comment></comment><comment><USER16> They should start using F2FS, instead of patent encumbered exFAT and Co.

</comment><comment><USER17> >> The company is not disclosing the type of memory or the controller that power the SD PCIe card, but it is clear that we are dealing with a custom solution.

Just itching to know if it's got a RISC-V core in there.

<comment><USER15> Nope. Their RISC-V stuff is still at least a year away.

</comment></comment><comment><USER18> Hey, this might be good to replace the silly SATA DOM [1] that SuperMicro uses.

1: [https://www.supermicro.com/products/nfo/SATADOM.cfm](https://www.supermicro.com/products/nfo/SATADOM.cfm)

</comment><comment><USER19> Too bad there isn't a single good USB-C SD card reader.

<comment><USER20> Are things still that seriously screwed up in the USB-C ecosystem? I was hoping they would have figured things about by now.

<comment><USER21> Up until USB 2.0 and to a degree, 3.0, USB was pretty straight forward in the fact that EVERY USB device plugged in worked.

Now you have USB C with a laundry list of supported features and protocols which may or may not be present on your device and most consumers are completely clueless. Does that USB C port on your device support Displayport? Does it do Thunderbolt? Can it be used for charging? What does it do exactly? Too many technical features in a consumer plug.

<comment><USER22> > most consumers are completely clueless

In my experience even many techies are clueless, myself included. I recently purchased a Lenovo* Thunderbolt laptop dock for my new Lenovo laptop that has a USB-C port, but quickly found out that this laptop does not support Thunderbolt: the dock plugs-in fine, but doesn't actually work. Apparently there is a separate "USB-C dock" in addition to their Thunderbolt dock, but I wasn't aware this was something I had to take into consideration.

I'm also left wondering what would happen if I took the USB-C charger for the laptop and plugged it into the USB-C port on my phone, or vice versa. How "universal" is USB-C anymore?

* I'm not a fan of Lenovo in general but that's what's available through work.

<comment><USER23> That's one of the reasons I bought the specific dock offered by Dell for my XPS 15. The laptop and dock support thunderbolt, but it's carried across USB-C. Getting this all right and knowing it will work as expected was enough for me to pay an extra $30-$40 to make sure I got a well tested docking system.

The article I just read to make sure I had my facts straight before posting[1] said it best I think. USB-C is a connector, which support many protocols (including USB 3.0/3.1 and Thunderbolt 3).

In other words, it's the equivalent to the Ethernet in your network, over which you run a protocol like TCP/IP, or IPX/SPX (not that I think anyone actually runs this much anymore). It's confusing because for USB 1.0 and USB 2.0 the protocol and the connectors were fairly closely linked (although they did downgrade as needed).

1: [https://www.quora.com/What-is-the-difference-between-a- Thund...](https://www.quora.com/What-is-the-difference-between-a- Thunderbolt-3-vs-USB-C-cable)

<comment><USER4> And yet, I plug an Ethernet cable into a switch manufactured 20 years ago, and it works great, albeit at slower speeds.

<comment><USER23> Twenty years from now plug a new USB-C cable into something manufactured twenty years ago and it may work too. You know what might not work too great now over Ethernet even if the connector works? An IPX/SPX device, since there's nothing to connect to on the other end. Your Ethernet network will be functioning perfectly, but you'll find yourself having trouble getting internet access because your router/firewall/etc are all running IP.

<comment><USER4> > and it may work too

It _may_ work. It doesn't even now.

And IPX/SPX work just fine. I was actually playing a DOS game over multiplayer the other night.

<comment><USER23> Multiplayer on the same LAN (or with translation software to TCP/IP), right? Meaning you connected two IPX/SPX devices over it and they worked together. That's expected. But you wouldn't expect to plug in an IPX/SPX device and DHCP an address and use the internet (which would be possible with a IPX/SPX aware NAT firewall), just as you shouldn't expect to plug a laptop that supports Thunderbolt into a bock that support USB-3.1 over a USB-C cable and expect it to work The medium works in both devices, but there's a protocol mismatch.

<comment><USER4> USB-C's situation is so bad that you have to know which of the identical ports have certain features. Your bridging argument is just a red herring.

I can plug two devices together locally over Ethernet and expect them to work. I can't expect that of USB-C. Do you not see the difference?

<comment><USER24> it's definitely a pain to have a single connector that may or may not support several different transport technologies and/or power delivery. on the other hand, it's way less bad than having to carry around a different cable for each of those _and_ having to cram all those different ports on the laptop.

my guess is that, in a few years, a standard set of the most useful features will stabilize and it will be cheapest to just offer that all the time. in the meantime we just have to deal with the growing pains and read benson leung reviews so we don't burn our houses down.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER25> This could be a great addition for laptops that keep SD card slots.

</comment><comment><USER26> I wonder if an expresscard adaptor could be made for these, after all it also is pcie internally...

This would be a way to give old laptops a real boost.

</comment><comment><USER27> Let's say I wanted to watch a large video from this SD card, wouldn't the transfer from SD card to display be slowed down by the bus between the board to the display?

Similarly, if I wanted to transfer the same video directly from the SD card through the bus, then through a network interface over a network to another computer, wouldn't the write speed be slowed be all those components in the middle?

I don't understand the write speed at 880 MB/s if it'll inevitably be slowed by many other slower components.

<comment><USER28> > I don't understand the write speed at 880 MB/s if it'll inevitably be slowed > by many other slower components.

This is very useful for high-resolution cameras, and even more so for high frame rate video shooting. No need for compression, just dump raw frames on the card.

</comment></comment><comment><USER29> Western Digital moves pins around and gets a press release out of it...</comment>


A four step approach towards securing your OpenCart shop - <AUTHOR> https://www.getastra.com/blog/4-step-approach-opencart-security/ <comment><USER2> TLDR; They want you to buy their firewall software</comment>


Why 40% of Tech Startups leave Atlanta in Three Years - <AUTHOR> http://www.pehub.com/wordpress/wp-content/uploads//atlanta-start-up-study1.pdf

<comment><AUTHOR> Found via PEHub: <http://www.pehub.com/50745/atlanta-georgia-startup-killer/> The paper itself isn't quite as strong as the PEHub headline, but I'm pretty sure that's how the authors are selling it to the press.

<comment><USER2> I reached out to the primary author. He was not aware that it was online.

While the paper has some factual errors and conclusions (I do not think that anyone within the Atlanta technology community would call it "rich in venture capital" as an example) I do think that the conclusion that Atlanta's tech sector lacks social structure is dead on. I wrote an article for the local paper to this effect last month: <http://blog.weatherby.net/2009/08/startups- are-hard.html>

I also think that a main point is missed within the article. Companies that leave Atlanta are not doing so for social structure reasons, they leave because the venture capital factor is based elsewhere and requiring the companies to move in order for a funding event to occur.</comment></comment>


Why I don't make movies anymore (and what I do instead.) - <AUTHOR> http://www.tonycomstock.com/2011/09/12/why-i-dont-make-movies-anymore-and-what-i-do-instead/

<comment><USER2> He'll be making movies again in 1 - 2 years. Sailing is boring.</comment>


The Granary Weevil: Pantry Monster of Our Own Creation - <AUTHOR> https://www.npr.org/sections/thesalt/2019/01/08/677763131/meet-the-granary-weevil-the-pantry-monster-of-our-own-creation <comment><USER2> Something didn't make sense to me: if the weevil evolved in the Himalayas and spread by human contact, how could there be a _maize_ weevil when human colonization of the americas predated agriculture and then restarted only about 600 years ago?

Turns out it goes after all sorts of grains, and is even referred to in the US mostly as a rice weevil. Which is a relief, as otherwise the rest of the article would be dubious. It looks like it was named as such solely because it was first identified as a species in the late 1800s, presumably in a transplanted crop.

It's also annoying that NPR called it "sitophilius" which doesn't make sense (the genus is actually Sitophilus -- "grain lover" which makes more sense, though that typo seems for some reason to be pervasive).</comment>


Spikability - An Application's Ability to Handle Load - <AUTHOR> http://blog.iron.io/2012/06/spikability-applications-ability-to.html

<comment><USER2> I'm confused: how do you use message queues to handle traffic spikes? If a user request is sitting in a queue, aren't they staring at a white screen until I get back to them?

edit: "And you can launch more servers to eat away at the queues if they keep growing." sounds a lot like autoscaling to me. The graph is misleading.

<comment><USER3> The pattern is to put the work in a queue, respond to the user immediately, then process in the background, outside the request cycle.

Regarding auto scaling, it is scaling your worker servers to work down the queues, but it is not as urgent/critical as auto scaling your app servers if they had to handle the load.

</comment></comment><comment><USER4> So, I understand they're trying to sell their product here, but please...

In most web-apps there is exactly _one_ user-initiated task that can be deferred: sending e-mail. Last time I checked my "spikability" was not bound on sending e-mails.

</comment><comment><USER5> I was going to use iron.io for a Hackathon, but didn't end up finding a way to use it in my project. I looked through the docs though and it's really interesting.

<comment><USER6> You might consider looking again. Check out this post ([http://blog.iron.io/2012/05/new-ironworker-command-line- inte...](http://blog.iron.io/2012/05/new-ironworker-command-line- interface.html)) about new .worker files and ng gem (<https://github.com/iron- io/iron_worker_ruby_ng>). Docs are really improving rapidly too. Finally, don't hesitate to stop by the support channel (<http://get.iron.io/chat>) with any questions.</comment></comment>


Operating Systems Need Pervasive Sandboxes - <AUTHOR>

While code will always be buggy, application oriented hacks shouldn't be that damaging.
Our OSs should be doing more to protect us.  We should be applying sandbox's across the board.
Yes, it requires us to think a differently about how we construct apps, but there's very little reason my "web browser" needs full access to my computer. In fact, there is zero reason why my banking and general browsing browser sessions should be running in separate sandboxes.  They can be the same underlying binaries, but they should be running as separate processes in kernel enforced sandboxes with some OS provided UI sugar to enable to the user to differentiate.
Apps shouldn't be viewed as single programs, but as the collection of programs needed to do a job.  your web browser app is firefox, chrome,... + whatever needs to run in its same space (i.e. plugins). You banking browser app might be the same underlying firefox, chrome... but without any of the plugins.
Of course, web browser's also have external helpers for downloaded content (office apps, media viewers...). All one needs is the ability for a program in one sandbox to launch programs in a separate sandbox.
Now, this is a problem, as they can infect that other sandbox (i.e. don't want a malicious PDF forever infecting my PDF viewing sandbox). But here we can have ephemeral sandboxes.  Every time firefox hands off a pdf to a viewer, the OS creates a new sandbox instance that is thrown away once it's finished.  Even if you do view a malicious file, it's changes it would be thrown away once you stop viewing it
Of course the big elephant in the room is depending on the kernel providing the proper enforcement, the obvious direction an attacker will take is to try an attack the kernel itself from within the sandbox.  However, most of these compromises are user level compromises and there's minimal reason our OS's should be allowing them to happen.
thoughts? <comment><USER2> With all due respect HN is not your blog.

<comment><AUTHOR> generally when someone uses "with all due respect", they mean they don't have much respect :)

what's the difference between writing this up on a blog and linking to it and just including the content here?

<comment><USER2> I meant it politely. A terse "HN is not your blog" sounds rude in my opinion. I think manners and social graces are important.

One of the big drawbacks in my opinion is that your post contained no links, because it could not. Because you can't put links in I think it means less research[1] and effort is put into the post. I also think that setting up your blog somewhere else raises the level of investment ever so slightly that it cuts down on some frivolous posts. Finally the domain to your link would appear at the end of the post title. I use the domain (and I think others do to) as an information filter.

[1] See <http://wiki.qubes-os.org/trac/wiki>

<comment><AUTHOR> I'd also point out, that my main motivation in writing this was to provoke discussion (a few links provided, though probably wish there was more). I honestly figured this was the best way to accomplish it in a centrally located comment area. though I do take your critique to heart.

</comment></comment></comment></comment><comment><USER3> Yep, see EROS and Capsicum.

<comment><AUTHOR> yes, though those require things to be seriously rewritten, I'm not convinced this can't work with existing code and putting the changes into the OS itself. Unconvinced apps needs fine grained sandboxing, even if they can benefit from it.</comment></comment>


AngularJS Cheat Sheet [pdf] - <AUTHOR> https://dncmagazine.blob.core.windows.net/downloads/AngularCheatSheet-DNCMagazine.pdf <comment><USER2> This looks like a good resource. But number 28 is wrong:

> Always have a '.' in your ng-models which insures prototypal inheritance.

That isn't what that does. The egghead.io Angular videos also get this wrong. I really think that the vast majority of Angular programmers don't really understand how its scoping works. I've ranted about this before [1], it's just ridiculously complex.

Some scopes inherit prototypically from their parents, and others don't, and you can't tell or affect it from the markup. The dot just means you're referring to a property of an object on the scope. If the object is somewhere in the scope inheritance chain, two directives attached at different points in that chain can share data by pointing to the object. If the object isn't there, what the name points to is actually non-deterministic. Ng-model silently creates it, and the point in the chain at which it creates it depends on which directive wanted to write to the property, which might depend on the order in which the user interacts with the different elements on the page.

[1]: [http://larseidnes.com/2014/11/05/angularjs-the-bad- parts/](http://larseidnes.com/2014/11/05/angularjs-the-bad-parts/)

<comment><USER3> > Whatever the reason is for Angulars popularity, it isn't that it's a great > framework.

Anything that makes programmers productive is a great tool. Angular 1.x definitely makes teams productive. It's one of the first web framework that comes with a specific testing framework. The clear separation between the DOM and the business logic makes apps more testable. And I could go for hours. Angular helps developers write complex apps faster and better.

Sure it isn't perfect, but show me something better with all the features AngularJs has.

AngularJS didn't became popular because it was from Google, a simple proof is the closure widget library nobody uses outside google. AngularJS became popular because it was obviously superior in term of developer experience.

Now your point about ng-model and scopes is valid.But it's not a angular problem, it's a javascript issue.Ultimately to understand angular you need to understand how javascript works, which many develpers don't.

Instead of saying "this thing is bad", Educate them. But I guess sensationalism drives more clicks.

<comment><USER2> I got tons of both hate and love for that blog post. One of the few criticisms that I can accept is the "The problems are real, but don't matter that much." view. I don't agree, but I suppose people can have different experiences there.

Any 'sensationalism' comes from legitimate anger with the framework, after having spent over a year working with it on a large project.

> Now your point about ng-model and scopes is valid.But it's not a angular > problem, it's a javascript issue.

This I don't agree with. Yes, JavaScript has prototypical inheritance between objects, but certainly not between scopes. It has lexical scoping like everyone else. The decision to have scopes be objects that (sometimes, not always) inherit from one another, is entirely on Angular. So is the decision to have ng-model silently create objects on this scope.

<comment><USER4> > after having spent over a year working with it on a large project

What issues are you running into? I always hear people complain about angular but rarely hear why.

<comment><USER5> Most people don't understand directives, so they resort to a pub/sub communication model that makes the web page unable to scale when you have too much items that are binded/coupled on a page.

No optimizations are possible for an exponentially resource greedy problem.

</comment></comment></comment></comment></comment><comment><USER6> I love working with angular, but the intense competition from other technologies combined with the overall negativity towards it has turned me off. The long term future of angular seems very uncertain.

<comment><USER7> Angular 2.0 is the New Coke of web development.

I suspect Google would gain a huge amount of goodwill if they backed down and announced: "You know, we'll rename the incompatible redesign as AngularNext 0.1 and use it to develop cutting-edge ideas. Then we'll bring the best of those into the mainstream Angular over time without breaking compatibility."

They could call the rebooted compatible Angular 2.0 "Harmony".

<comment><USER8> The Angular team is not going to do backwards compatibility with Angular 1.x with 2.0 at all - they're going to help with migration some with the router, but the api are fully incompatible.

FWIW, Angular 2 is awesome to work with, even in its alpha form. Productivity with it should be immensely improved compared to 1.x.

</comment></comment></comment><comment><USER5> 14 pages for a cheatsheet!

The ones for emacs/vim are 1 page only, I guess we have a measure of the complication of angular now.

<comment><USER3> Give us a fn break, did you actually read the pdf? that's not a cheatsheet, more like collection of recipes.

> The ones for emacs/vim are 1 page only,

Apples and Oranges

> I guess we have a measure of the complication of angular now.

AngularJS isn't rocket science. But maybe we don't have the same definition complexity , which makes sense if you are a skiddie.

<comment><USER5> You are right, I should not compare apple and orange: you can edit text, play soduku, do syntax highlighting easily, search/replace with regexp in vim, while in angular JS you can only do slow, unusable data bindings. So comparing the 14pages of angular sheet is way too much of a disgrace for vim or emacs.

Btw, I use kate that need NO cheatsheets, because mastering an editor does not make me a better coder...

EDIT: ok I also use vim, emacs, joe, nano, ultraedit, gedit, visualstudio, netbeans, eclipse, nvi, simpletext, texmate, sublime ... whatever the guy paying me want me to use even if it is stupid.

</comment></comment></comment><comment><USER9> I love cheat sheets! I actually consider them the best way to learn a framework. This one's excellent. Wish I could find one as good for Meteor.

</comment><comment><USER10> > 24\. Wherever possible, use AngularJS versions of JavaScript functionality. > So instead of setInterval, use the $interval service....It becomes easier to > mock them or write unit tests

I've always been very against these angular versions of basic js functions because it requires everyone on the team to learn them and it puts you even deeper into the angular lock in swamp, hindering you from eventually changing your view-framework in the future. Any takes on this?

I like the data binding of angular but try to restrict angular coming in contact with "core" code. As example we hardly write any services, we just use them to hold an instance of plain js-classes that can easily be reused in non angular projects.

<comment><USER8> Services such as $interval or $timeout are very simple - $http is also a fairly simple service to replace too. I don't really view it as much of an issue when it comes to lock in or migration, there are usually far more perilous pitfalls when it comes to lack of being able to migrate, such as bad app architecture or hacks.

</comment></comment><comment><USER11> Sadly will only be valid for ~6 months.

<comment><USER12> What's happening in 6 months? Is my angular code going to spoil?

<comment><USER13> Haven't you heard? All Angular sites are going to self destruct, and the Github repo will cease to exist.

</comment></comment></comment><comment><USER14> Nice domain name.

<comment><USER15> In my opinion this is hosted on Azure and all azure containers have the same domain name (for obvious reasons).

Nice cheat sheet though!

</comment></comment><comment><USER16> It'd be nice to see a UI Router cheat sheet in this format as well. I'm always forgetting nested syntax.

<comment><USER17> I would avoid investing too much in UI Router. As soon as the new Angular 2 router is available, it should be used for Angular 1.x projects as well to support migration to Angular 2 in the future.

</comment></comment><comment> oi-sendai Thanks for posting this. Really looking forward to trying out some of the unit testing advice!

</comment><comment><USER18> Nice! Perfect addition for my [http://ihateangular.com/](http://ihateangular.com/) !

<comment><USER19> You seem to be spending on a lot of energy on your hatred.

<comment><USER18> I am getting enough energy kick from my angular day job on pretty intimate level :) Also, it serves me as a collection of "gotchas" to point to new devs.</comment></comment></comment>


The Many Layers of Packaging: Why PyPI Isn't an App Store - <AUTHOR> http://sedimental.org/the_packaging_gradient.html <comment><USER2> > PyPI, pip, wheels, and the underlying setuptools machinations are all > designed for libraries. Code for developer reuse.

Many Python applications seem to disagree with this point. The one I most recently deployed, Mayan EDMS[0], includes installing the application using pip.

On a side note, one thing that's always driven me nuts about having multiple package managers is that they don't talk to each other. If I install a system- wide Python library using pip, the system package manager isn't aware of it and will try to install the vendor-provided, and usually older, version to satisfy a dependency.

Likewise, there's no way for pip to ask the underlying OS to install some dependencies - just look at the packages you have to install to get Mayan EDMS running. This isn't as simple as asking for a given package name, you have to ask for the name that the underlying OS/package manager knows that package by. For example, "apt-get install postgresql" might suffice for Debian, but on FreeBSD you might need something like "cd /usr/ports/database/postgresql96; make; make install".

I'm not singling out Mayan EDMS here, it just happens to be the most recent bigish Python application I've installed so most of what I went through is fresh in my mind.

[0] [https://mayan.readthedocs.io/en/latest/topics/deploying.html...](https://mayan.readthedocs.io/en/latest/topics/deploying.html#os- bare-metal-method)

<comment><USER3> Python/Ruby/Node all suffer from this - the OS stubbornly thinks it knows what's best. Here's what I do.

1\. Ignore the OS when developing - let it manage its own dependencies for its own Python - fine. I use pyenv/rbenv/nvm to install my own dev. version of <language> and use isolated virtual environments for developing.

2\. Deploy using Docker - again - ignoring whatever the OS has installed.

<comment><USER4> That's kind of by design. You're supposed to develop with virtualenv. Then, if someone packages your app for inclusion into the distro, it's on them to package the compatible dependencies and your app. (I mean, it would be nice if the devs helped here, but that's what distribution maintainers are for)

Not sure why you need docker though. It's fairly easy to distribute python libraries in a simple tarball.

<comment><USER5> If you want to do something like kubernetes you need to slap your python tar into a docker image.

<comment><USER4> Not sure I understand your point. Kubernetes is a service for managing containers. If you want kubernetes, of course you'll need containers of some sort. But not all apps need multi-host orchestration.

</comment></comment></comment></comment></comment><comment><USER6> I love the fact they discuss hardware as a deployment strategy.

I considered the same thing at one point where I needed to suggest a bullet- proof way to run some Python code internally at a range of customer sites. A Raspberry Pi plugged into their network isn't a bad fix. The amount of time saved by pushing all configuration issues on to the internal IT department outweighs the hardware cost by a few significant digits.

I'm not sure the sheer cheapness of hardware has really sunk in yet. A lot of problems might be better solved by snail-mailing small computers to people.

<comment><USER7> "Network appliances" were a big market for this kind of thing. We've also found it worked for us in the point-of-sale business.

<comment><USER8> appliances are still a big market for really large companies with money to spend.

it's kind of a dream for these kinds of clients; the only thing you're responsible for is "plugging" it in. the vendor owns everything else (and gives you access to very little of it!). this is also great for the vendor because they can sell what essentially amounts to a server that does all of the magic at a ridiculous markup without much regard to the quality of the software underneath (unfortunately)

i cracked open a vendor appliance a few years ago. it was very much like opening an abandoned closet that's been untouched for 50 years. not pretty.

</comment></comment></comment><comment><USER9> Hey HN. Current conda lead developer here. Just want to highlight that transactional rollback for all disk mutating operations (create, install, update, delete) was a big feature in our latest release series. We've closed over 1,000 open issues in the last several weeks, in large part because of the problems that transactions solved.

<comment><AUTHOR> Ohhhh snap! I'll update the article tonight!

</comment></comment><comment><USER10> "The mark of an experienced engineers is to work backwards from deployment, planning and designing for the reality of production environments."

Important point!

<comment><USER7> The software equivalent of limiting pre-fabricated building pieces, wind turbines, space shuttles etc. by the size of the largest bridge they must pass, or other constraints of rail or canal delivery.

<comment><USER5> You mean the size of the smallest bridge?

<comment><USER7> Oops, yes.

</comment></comment></comment></comment><comment><USER8> lovely article.

i don't agree with pip not being an app store. the best way to deploy something is to deploy onto the most convenient medium for your target audience. so if i need a cli tool or app that happens to have an API, pip or homebrew/chocolatey/yum/apt/etc are the best delivery mechanisms for it. however, i wouldn't tell our execs to pip install some app they need; i would self-contain everything, ship it with a pretty installer and host it on s3.

that being said, rpm's or deb's are a great way of packaging anything to *nix servers and have been for ages. yum and apt are pretty much guaranteed to be available and the rpm build file format is pretty powerful (albeit unfriendly to look at). we've deployed app artifacts via rpm with good success

</comment><comment><USER11> Just in case you tl;dr

"A summary of our lessons along the way:

1\. Language does not define packaging, environment does. Python is general- purpose, PyPI is not.

2\. Application packaging must not be confused with library packaging. Python is for both, but pip is for libraries.

3\. Self-contained artifacts are the key to repeatable deploys. Containment is a spectrum, from executable to installer to userspace image to virtual machine image to hardware.

4\. "Containers" are not just one thing, let alone the only option."

<comment><USER12> > pip is for libraries

Since when?

<comment><USER13> pip & similar package managers are a trainwreck everywhere but on developer machines.

<comment><USER14> Huh. I'm not originally from the python community, but I had no trouble figuring out how to get reproducible installs out of pip using the requirements.txt idiom.

<comment><USER13> The issue with using pip and package managers in a similar vein is that they're not distributing complete packages, which usually means that stuff is compiled when installing some application. End users don't have compilers, and ideally you'd want to avoid them on servers as well. Often this also needs some or many OS-level depencies, like libraries and headers.

There are of course many other issues with pip and setup.py, far too many for a comment here.

But to give just one example; distutils/setuptools try to play god ^W build system with things like Extension. This works, badly. For example, most compilers that aren't GCC or MSVC compatible are not supported at all. Finding libraries? Not supported. Having proper dependency graph detection of files? Nope. If some "invisible" dependency of an output was modified, won't recompile. Ups. It pretty much behaves like a Makefile written by a naive person, just without the "-jN" flag.

<comment><USER13> Now I know that the PyPA guys do a ton of work to make all this stuff less brittle, and indeed, Python packaging has improved a lot over the years. But overall it's still brittle, complex, difficult to debug and reproduce, and generally falls apart randomly with a frequency that does not inspire trust.

<comment><USER15> There's not really a lot you can do about this though, is there?

It's not that hard to test that things work, or to see the failures. Comments I've seen like 'there should be a server that installs every package on its own and makes sure its tests pass' have a bit of an issue: we already know the issues exist. Having a big list of them in one place doesn't really give us a lot more information.

What's the _solution_? If you need to compile native dependencies, how do you take PyPI and Python packaging in general and make those native dependencies able to be portably compiled, reliably, on any platform?

Things that are straight up unworkable:

* Bundling native dependencies as binaries * Specifying a single version of your native dependencies (the 'shrinkwrap' approach) and every library having its own

<comment><USER16> > Building native dependencies as binaries

Yep. [http://conda.readthedocs.org](http://conda.readthedocs.org)</comment></comment></comment></comment></comment></comment></comment></comment>