React is the new jQuery - <AUTHOR> http://bradfrost.com/blog/link/replacing-jquery-with-vue-js-no-build-step-necessary/ <comment><USER2> > React is the new jQuery

Anyone who uses "the new jQuery" as some sort of insult (as it seems Sara did in her tweet) probably hasn't been a developer for more than a few years or is just trying to sound smarter than they are by bashing an easy target.

The reason jQuery got so popular is that it made common tasks so much easier than anything else at the time. Anyone who was doing web development before jQuery knows what a godsend it was at the time. JQuery was a fantastic leap forward for development at the time it was released.

JQuery didn't become bad, the rest of the development world caught up and made it unnecessary.

<comment><USER3> I don't think JQuery ever got bad. It just got unnecessary, like you said. But it took a lot of work to convince people that it was unnecessary.

A charitable explanation of Sara's tweet might be that, like with jQuery, it is becoming difficult to convince new developers that React may not be necessary for their next project.

The other comparative downside of JQuery was that components started to rely on it as a shared library, which meant developers suddenly needed to do dependency management. That is (usually) a bad idea. React absolutely does have that problem as well - probably to an even worse degree than jQuery widgets ever did.

This is kind of the same concern I have with Vue to be honest. I use Vue for prototyping and will probably use it in some final apps as well. But I'm probably not ever going to use a component that someone else has written if it relies on Vue.

IMO Lodash went the right direction with this. A component or library can depend on Lodash, pull in _just_ the functions that they use for a final build, and then nobody else in the entire dev toolchain needs to know or care. No risk of conflicting dependencies, build size stays low, etc...

I kind of wonder if the problems Vue solves for me could be solved better by a smaller, lodash-style library instead of a framework.

<comment><USER4> Being used to jQuery, I really see no reason not to use it in new projects. I could learn all the new native equivalents, and even then still ending up doing more work than if I'd been using jQuery, just to save a little bit of page load time and filesize, but it would almost certainly not be worth it.

<comment><USER5> It irks me that Javascript didn't just adopt the best parts of JQuery.

<comment><USER6> There are still things you can only do with jQuery, I can't think of a better Swiss Army knife for small tasks.

</comment></comment></comment></comment></comment><comment> rich-and-poor Oh Brad, you do not know what you are talking about right off the bat. Let's go through your list.

1\. Every document has a root node.
 is your root node now. You had a root node before, you have a root node now.

2\. Do a search and replace. That's easy.

3\. That's another search and replace.

4\. You don't need to call a constructor, you don't need to use bind, and you don't need to assign your functions to an variable on your class instance.

React allows you to compose things. Make something once and use it everywhere. You write much, much less code. You get lifecycle hooks for when things mount, update, unmount. You get easy templating in JSX. You can also ditch the whole thing for Inferno if you care about having no lisence or company behind it.

You also get amazing libraries for state management and async via reactivex.

<comment><USER7> I like Brad's articles, but recently it has seemed like he has struggled to migrate on React, and some recent articles have just been trying to criticise React but with bad (or false) arguments, which makes it appear just him trying to justify himself not being able to wrap his head around.

React is great, mostly for bigger web apps that do need a framework and more structure, such as an SPA with multiple team members working on it.

Just like jQuery is great to do some quick and simple dom manipulation.

I've tried both opposites; I've been on teams working on large apps in jQuery, and it's hell. And I've also used React to implement simple little things, and it's also hell (part of it for reasons Brad mentions in this article).

I don't have much experience with Vuejs but I've been using it instead of React recently, and it's refreshing indeed. Just like jQuery you can just import it with a script tag and start doing some dom manipulation and it makes the code much cleaner than jQuery.

And as others have said, jQuery is not bad - it's awesome. I guess it didn't age very well with the JS env evolving, but it's great.

<comment><USER8> >React is great, mostly for bigger web apps that do need a framework and more structure, such as an SPA with multiple team members working on it.

I'd argue this is bad advice. What constitutes a 'bigger' project us arbitrary, and once you build your whole app on jQuery it's expensive to migrate to React once you get just a bit 'bigger'.

Now whether or not all websites need to be React-based SPAs is a different question entirely.

<comment><USER7> yeah you are right about the cost of migrating, I've been through one and it's indeed to be avoided.

I badly used "bigger". What I meant was more in the lines of React is great to build what we could call web apps - something with complex logic, etc. While jQuery is better for simple DOM manipulation.

Maybe a good line is, as soon as you find yourself manipulating data you might want to think about using a framework such as React.

</comment></comment></comment></comment><comment><USER9> Ok, so Brad is already making sweeping declarations about React, yet less than a month ago he specifically posted about his struggle to learn it: [http://bradfrost.com/blog/post/my-struggle-to-learn- react/](http://bradfrost.com/blog/post/my-struggle-to-learn-react/) cool...

<comment><USER10> Almost like some people don't quite get that's its intended to be used for complex applications rather than just websites.

</comment></comment><comment><USER11> > Burn all of your markup down to the ground and replace what you had with >

This isn't totally true -- if you really only wanted to implement a single toggle and leave the rest of the page alone, then you could replace just the relevant DOM elements with a container and render into that fragment of the page. (Though really I'd ask why use React if that's the only value you're getting out of it)

> I guess that's why I'm still struggling to comprehend why so many > organizations are so eager to take the sturdy, foundational layer of the > frontend stack and rewrite it all in a proprietary format. [...] Projects > like Vue are showing that's not necessary.

Except, Vue.js does require a proprietary format; all those v-* attributes and custom components will be need to be migrated if you want to switch away from Vue. Comparatively, React is better in this regard because there are multiple implementations of React (preact, inferno, nerv). Also, JSX is technically optional, and it's really easy to mix markdown, or other formats/templating engines into a React app to handle the content-heavy bits.

<comment><USER12> I feel like the word "proprietary" means something different to me than the author. When I think of proprietary I think of a closed standard that may or may not be copyrighted/patented. Something like React would not even come close to my definition.

Wikipedia seems to agree with me [1], but maybe I'm misinterpreting it:

[1] [https://en.wikipedia.org/wiki/Proprietary_software](https://en.wikipedia.org/wiki/Proprietary_software)

</comment></comment><comment><USER13> I think there is some confusion comparing jquery with frameworks in general heh- time for a history lesson! So back in the mid-aughts right before jquery there was prototype. I got hired into a job where I had to maintain sites written with both in the past and they were very similar to each other. Ajax was new and so was the class based handling of JS to make it more object oriented. It could be done but prototype made it convenient. It was possible to manipulate objects before applying them to the DOM however it was really verbose...academic I would call it. Then prototype's cool younger brother arrives (jquery) and it became so easy to pull this stuff off it was like a giant party. Learn jquery? Your hired! Ahh the halcyon days ;) Anyhow- if you've lived through things like CGI and DHTML (and java servlets to a lesser extent) they were like the malaise era of web dev but jquery flipped the tables there has been NOTHING like it to date. We've gone back to academic with colorful packaging (I'm lookin at you angular!) and react coupled with redux just isn't the same- it's interesting but not a quick study. So..back then we could pick up a program in 24 hrs book and land a job. Today we can read 24 books and scratch the surface. Jquery was a movement not a framework and the statement being made was life is too short to NOT be incredible, we can all be incredible with jquery so why not? More comparable to the Misfits showing up to a Johnny Cash show than just another framework...just my two cents.

<comment><USER14> There were also mootools and dojo.

I was more into those two but jQuery made everything dead simple.

<comment><USER15> and dont forget scriptaculous :)

<comment><USER16> I'm having flashbacks to 2006! mootools, dojo, prototype, scriptaculous, jquery.

<comment><USER17> Sometimes all on the same page!

</comment></comment></comment></comment></comment><comment><USER18> A common flaw in software engineers is writing thinkpieces about technology they don't fully understand yet. Giving it a clickbait, not fully baked title is a bonus.

Move along. Engineers will continue to use good technology they understand (like React) while newcomers will continue to try to emotionally justify technologies they don't want to learn and use.

</comment><comment><USER3> I agree with the spirit of what he's saying, although I don't think jQuery is a very good comparison to use.

React is a decision. I'm speaking in broad generalizations because I don't know how to put this principle into more specific terms, but good programmers should avoid making decisions for as long as possible. This is the same reason why I caution people against using test frameworks. Most of the time when you start coding an application you won't have enough information to make any educated decisions about it.

This is a huge advantage that Vue has over React. You can use Vue for just one component out of your entire app and it's fine. It is fairly easy to separate it from all of the rest of your application logic and that means by extension it's fairly easy to rip it out later. Or at least... easy enough.

It's still not perfect. I dislike how hard it is to make its templates fail gracefully when Javascript is disabled. I dislike that it uses setters in its data model, which discourages immutable programming. I dislike a few other things as well.

At some point, someone will make a better framework than Vue, probably by building something even smaller and even more focused than Vue already is. But in the meantime, if you are going to use a framework for two-way data bindings, you should probably be using Vue instead of React. Opinion me, of course.

</comment><comment><USER19> Let's not forget that jQuery was a polyfill that allowed JavaScript Devs on all browsers to code to a common baseline. React is a nice —- and popular —- library for building UIs but it's existence isn't an indictment of the laziness of standards implementors for browsers (okay, IE mainly) and god-send to developers like jQuery was.

<comment><USER20> Yes, React isn't _exactly_ jQuery, but it gives the same level of productivity boost comparing to development with just the modern DOM APIs (querySelector, classList, etc).

<comment> crooked-v For a large project, React gives you way, way, way more benefits than jQuery does.

</comment></comment></comment><comment><USER21> _If you tear out something like jQuery, you're going to have to figure out a way to get those accordions to expand and collapse again. If you tear out React, you get a blank page. React is a big commitment._

This is probably the only real concern I see.

jQuery is a library for DOM manipulation. It can co-exist with many other libraries.

React is an entire framework.

These days you need jquery less because browsers are more standards compliant and css animations basically work.

The trick is about using the right tool for the right job.

We have several large react applications - these are user-interaction heavy rich single page apps.

But we also use vanilla html and jquery dom manipulations in many other places.

<comment><USER22> What does "an entire framework" mean? Because you can just make React the little news and weather widget in the corner of your app / website, as the only React component. Same with Vue.

The people for whom ripping out React or Vue leads to a blank page are those who wanted an app from the ground-up.

If anything, React is losing because it doesn't include enough out of the box. If you wanted to build a news widget, fine. But if you wanted to build an app, you have to start putting pieces together from 3rd parties (or write your own custom pieces). That's not what a framework sounds like to me, that sounds like figure-out-your-own-framework, and I think that's why Vue is winning.

Create React App was a very late response, and I still don't think it's as good as Vue's up-and-going tooling experience.

<comment><USER23> > What does "an entire framework" mean? Because you can just make React the > little news and weather widget in the corner of your app / website, as the > only React component. Same with Vue.

Is there a step-by-step tutorial for this? I was googling for one yesterday, because I have a legacy app and want to start moving small components (like datagrids) out of server-side rendering and into components.

The best I found was [https://reactjs.org/docs/add-react-to-an-existing- app.html](https://reactjs.org/docs/add-react-to-an-existing-app.html), which reads like it would make sense to an xperienced React developer, but not someone coming new to it.

<comment><USER22> Do you find it difficult because it suggests you need to deal with JS modules and building? After you get your tooling setup, you can just include a node in your DOM that React will target and mutate.

<comment><USER23> I find it difficult because of understanding how to get it to fit with an existing directory layout. And maybe existing scripts in the build. But yes, setting up the tooling is overwhelming.

create-react-app says in the README: "If you need to integrate React code with a server-side template framework like Rails or Django, or if you're not building a single-page app, consider using nwb, or Neutrino which are more flexible."

So I go and look at nwb and Neutrino, and there's nothing there going "Need to use us in a legacy project with its own directory structure? Here's how".

I feel I'm missing a piece of the jigsaw...

<comment><USER22> I might prescribe that you go to reactiflux (not associated) or other popular chat communities to get some more live help for getting your tooling up. I suspect that if tooling were resolved, so much discussion of churn would disappear overnight.

</comment></comment></comment></comment></comment></comment><comment><USER24> Moved from Vue to React. A couple things drove this: Typescript support for Vue was kind of weak, and the interception of events and reactive elements ended up creating more bugs. I do love how Vue is easy to get up and going fast, but React seems more compatible with a growing team where you want stronger guarantees.

<comment><USER25> First time I read someone moving from Vue to React. I thought trend was only from React/Angular to Vue?

<comment><USER26> Vue works better for small apps, or progressive enhancement (similar to jQuery)

React works better for teams working on applications that need build tooling and dependency management anyway.

Angular, frankly I don't see why anyone would pick it over the other two. Yeah, it's got more in the box, but that bigger box takes 4x as much effort to lift off the ground.

</comment></comment></comment><comment> huy-nguyen I think people got carried away with the JSX side of React (which IMO is really just the icing on the cake) and forgot that React was probably the first view library that introduces the notion of the DOM as a pure function of data. It made functional programming mainstream in front-end development. This purity makes UI extremely easy to reason about and makes all DOM changes tractable. I was in a Backbone shop before using React and I remember Backbone was such a chore to manage in a large application. We switched to React and never looked back.

<comment><USER12> > _It made functional programming mainstream in front-end development._

I totally agree, and in fact I would take it a little farther and say it's making functional programming mainstream on the _backend_ as well. Many people I've worked with got their taste via React/Redux and then started adopting things like Elixir/Phoenix for the backend.

Maybe it's an overstatement, but I credit React with driving at least some of that.

</comment></comment><comment><USER27> The problem was never jQuery. jQuery performed a very necessary function when it was created. It was always the intention of the lib to cease to be needed over time. The problem was/is the ecosystem created around jQuery. Want to do a thing? Do it with jQuery. Want to read a cookie? Use jQuery. Want an image carousel? Build it with jQuery. Want to do anything at all? jQuery.

I do see something similar happening with our more junior devs. Their Google searches have now turned to "how do I read a cookie with React?"... and sure enough, there is a react-cookie lib - which may or may not be useful for their task... but since it says "react", it'll probably show up in a pull request. React can't be blamed for this though. All the ecosystem being built with the expectation of "well everyone's using React", _is_ a problem.

Education about separation of concerns is the only solution I can see.

</comment><comment><USER28> Brad Frost makes most of his money telling people what they should do instead of actually _doing_ himself.

He's given hundreds of talks all over the world about a component-based approach to style guides in web, but yet cannot fathom the need for React.

</comment><comment><USER29> I find myself defending myself a lot these days here. I use vanilla js. Never had any trouble, I literally have no bundle, no dependencies, the amount of code I have to write is basically the same either way, no trouble syncing state with DOM either. Have done so in two moderate projects (40k, 15k). Everyone I meet looks at me like I'm crazy. But in the same breadth say the site feels so smooth and responsive. No shit.

Catch being you he to learn how to write js but that's true for any framework as well. And frameworks have smaller shelf life anyways.

<comment><USER30> I agree you can do that but I feel like frameworks are more about teamwork. I can't imagine having a team of 10 with varying levels of JS experience/passion and telling them all to "just write nice simple vanilla JS that we can all agree is clean and simple" and expect that to happen.

<comment><USER29> I don't have a ton of experience leading team's using react, angular etc but I assume you are referring to the fact that there are multiple ways of doing things in vanilla js world whereas only one way in react world. That can make things easier for teams but I believe that's a lazy excuse. Choice is never a bad thing and it's literally the job of a tech lead to establish conventions, tell devs what flow to follow. If that turns out to be too difficult then it's not the code or framework's fault. Staying strict about how to do things is a concept that exists irrespective of framework or no framework.

<comment><USER30> Have strict team conventions and being afforded the time to try an enforce them is great. Agreed. It doesn't always end up working like that in my experience though. Frameworks often have a community that provides some convention guidance. Rails, for example, is huge on this. You can tell a developer "stick to the general Rails way of doing this" and they will often be able to follow that instruction. Is that lazy? Sure, probably. But I also consider it to be a feature of a framework.

</comment></comment></comment></comment><comment><USER31> React has a lot of inertia behind it, although it doesn't really make things easier.

The amount of js code to make even basic things work is high, and with so many different styles of writing react/js code, large codebases require significant effort to keep maintainable.

Which is to say, with this much effort put into structuring maintainable react js code, one could pretty much develop in any js ui framework (including jquery, backbone or none whatsoever) - since little of this effort is dependent on react, or made easier by it.

<comment><USER32> Virtual DOM and ability to derived your DOM state from props and state is not something you can easily done with jQuery or any UI library that doesn't have that concept.

It's not something you can easily implement yourself either.

That's the main part that makes React code maintainable.

<comment><USER33> I agree, this is the part that people seem to be ignoring. Yes, you can make a proof of computational equivalence between jQuery and React, but you cannot deny the massive increase in human usability that an set of components brings. There's far more interesting set of things you can do, Redux + the litany of other related libraries, a vibrant ecosystem unto themselves, prove this. I started my career out slinging jQuery and after 4 years of React I never want to go back.

</comment></comment></comment><comment><USER34> I really like the linked Vue/Jquery article in the story as well. I've built some stuff in Vue and I really like it. It can be incredibly simple.

I'm not a huge fan of React. I'm really not a fan of any site that requires Javascript to view. If it's a new article and I get a blank page, I immediately stick it in archive.is. I'm not turning on Javascript for your site just to view content. Fuck that. Fix your site to not suck shit.

I realize you can easily get into the same thing with Vue .. and I think Vue, React and others, makes sense if you're actually running a web application. Your main page, login page and other content pages should be static, no Javascript required. If you have a new site or a blog or graphics, why the hell are you requiring React/Vue/Angular or some other framework? Just display the content.

I haven't really looked into server-side rendering, but I suspect that still requires Javascript to be enabled on the client? Are there any newer Vue/React style front-end frameworks that are designed to still degrade gracefully without Javascript? (I suppose you can't really do this without pairing it with the backend language on the server).

I really like how Hackernews still supports a Javascript-less system, even for things like up/down votes (although I still turn JS on for HN to avoid page refreshes).

<comment><USER26> React can definitely use Server-side rendering... but it's often used for pre- render caching, and even doughnut caching to bootstrap the full application on the client, so you see content sooner. But, it's entirely possible to pre- render and degrade gracefully.

Is it worth the effort for a fraction of a percent of technical users whining about the need for JS? probably not.

</comment></comment><comment><USER35> When I see this:

        var formname = $(this).find('.formname');
        formname.empty();
        formname.append(n_input);

I think why not just use plain Javascript and do this:

        document.querySelector('.formname').innerHTML=n_input;

Coders that are attached to libraries and frameworks always seem so afraid to use the tech already available. That they don't even look at how the basic solution would look like.

<comment><USER36> Sorry for being terribly pedantic, but the "vanilla" version just does not do what the jQuery code does:

\- `this` might not be document

\- find might return multiple elements, not just one

\- if nothing matches, jQuery does not throw unlike the vanilla version

I do understand it's just an example, but if you'd consider all the implicit cases the jQuery example covers, you'd end up with a lot more than a single line. I see your point, but using off examples like this don't really sell it too well.

<comment><USER26> assuming "this" is an element... `this.querySelector` if you're intending to match multiples...

        Array.from(document.querySelectorAll(...)).forEach(x => {...})

It's not *that hard... though forEach should be on your dom collection returned, if Array.from exists, but I started shimming Array.from long before either were standard.

</comment></comment></comment><comment><USER37> This is from the guy who posted recently about struggling to learn React.

</comment><comment><USER38> I don't buy it.

ReactJS is a power tool and it takes some learning.

If your primary concern is about your initial learning curve then you should look elsewhere such as VueJS but I'm glad of the power of ReactJS.

Changing class to className is not a big deal, nor are the minor other bits and pieces mentioned in the post.

</comment><comment><USER39> We're talking about two totally different programming paradigms here. The end product might be the same but it's more of a question about how you arrive there.

With JQuery you're signing up for manual DOM manipulation. It's a challenge to scale that for what's now considered table-stakes for web apps.

</comment><comment><USER40> i just find it amusing that everyone gets up in arms what Brad Frost struggles with in React because he's famous. news flash: hundreds of devs face these issues every day and figure it out. Brad is famous and has problems with React; that's fine. He'll figure out a way that works for him. Doesn't mean his opinion at all reflects the experience of the thousands of devs who are happy with React. Let's move on and talk about more interesting things.

</comment><comment><USER26> Vue is for enhancing web pages.. you _can_ do applications, but they get very complex beyond small-mid sized apps.

React is made for building web-based applications. You _can_ do small stuff with it, but it's often overkill.

Just because you can use a butter knife to turn a flathead screw, doesn't mean it's the right tool for the job. These days I might reach for Vue as a jQuery stand-in, but more likely, I'd use a smaller jQuery-like library, or just use straight vanilla JS, or other micro libraries. For anything big enough to deserve a build process React is absolutely my first choice.

<comment><USER41> Vue can be used to enhance web pages, but it works equally well if you want to build a large application. This was one of the design goals. Something that you can start small and scale up with that works equally well for both. If you use the Vue CLI you can have a setup with a router and build tools and setup something very similar to create react app.

</comment></comment><comment><USER42> <3 jQuery, maybe nostalgia talking but still one of my favorite pieces of software ever. Made DOM manipulation fun.

<comment><USER43> > Made DOM manipulation fun.

same! Jquery is still quite useful and powerful. This is also what rails does for me; makes web development fun. Or highcharts making charts fun, or elasticsearch making search fun. To me that's a testament to elegantly solving a problem. I just don't get those fuzzies with react.

</comment></comment><comment><USER44> The JS world is so much more hype driven than say ruby, every few months they will have a new framework that promises to solve all the problems in ui land or the backend. They write songs in its praise everyone worships it like this is the one true framework a panacea for all evils. And then when the hype cycle winds down a new framework emerges. I am totally bored of looking at this cycle for the past few yrs. This just leaves a ton of unmaintainable projects in its tracks because the devs have found a new toy to play with. I have seen clients struggle to find backbone devs because no body in interested in Backbone this is a repeated pattern among JS Devs.

JQuery -> Backbone -> [Tons of Backbone wannabe's written in Coffeescript Batmanjs/Bananajs/what not..] -> Angular -> [Angular lookalikes with tons of magic] -> Ember -> Meteor -> React -> Vue -> [Wait a few months new framework in the Pipeline].

Unfortunately very few want to agree to the truth.

<comment><USER45> This just isn't true. React has been going strong for 4 years with no sign of slowing down.

<comment><USER44> I dont disagree, React has some solid underpinnings but for now VUE has some momentum, till the next one comes along. Google gave up on the idea long back. Google develops Angular but doesnt use it in any of their core products. They themselves use Google Closure library for gmail or word processor.

<comment><USER46> Isn't the new YouTube website running Angular? Please don't shoot me if I'm wrong, I don't have any citations, I just presumed (on phone, too lazy to look up).

<comment><USER26> Not according to Augery (angular chrome extension), but not sure if all evidence can be built out of the result.

However, mobile.twitter.com and facebook proper are using react. Along with Walmart.com and many, many others.

The biggest Angular app I've seen is probably grubhub, and there's some painful state bugs there... in fact I don't think I've ever seen an angular app (not using rxjs or redux) that doesn't have weird state management bugs.

<comment><USER46> I tried using Angular 1 when it came out and it seemed like too much work to learn for such a small benefit. I started learning React at the start of last year and have found it phenomenal. I am not comparing the two, let alone arguing in favour of Angular. I just thought with the swap to Material Design (and async loading data and components) in YouTube, that they were using Angular. Your opinion about YouTube using Angular (or not) has more citation and authority than mine, so I will assume in the future that YouTube does not use Angular (without certainty, of course).

</comment></comment></comment></comment></comment></comment><comment><USER47> Brad Frost has significant social capital and influence. That's the only reason this charlatanry is given the time of day.

</comment><comment><USER48> Sort of tangential, but React is way less painful with TypeScript/tsx. I combine that with an IntelliJ IDE (RubyMine specifically) and honestly, it's a lot of fun to write web apps this way. (Maybe that's because I come from an iOS background?)

Anyway, I recommend giving this setup a go.

<comment> huy-nguyen My first foray into React was done using Typesctipt. The functional nature of React plays very very with the static typing of TypeScript.

</comment></comment><comment><USER49> Just skip React and Vue and go straight to ReasonML/React, you will end up there in 3 years anyway

<comment><USER50> Had that worked well for you? Is it mature enough to use today?

</comment></comment><comment><USER30> As a member of a busy, small team with a Rails app and a jQuery heavy front- end... I agree. We use React in a few places and wanted to simply introduce it slowly and "convert to React where we could". It simply has not worked out for us. We have typical server side rendered HTML that has been progressively enhanced with sprinkles of JS (jQuery + various plugins). We do not and cannot book much developer time for refactoring and can only really improve the code itself in bits using the "boy scout rule" (leave the area you're working on better than you found it). For us, it turns out that yanking out chunks of jQuery and replacing them with React did not work out very well.

<comment><USER23> Thanks for sharing, this is exactly what I am considering doing at the moment.

Any thoughts on [https://news.ycombinator.com/item?id=17213264](https://news.ycombinator.com/item?id=17213264)?

<comment><USER30> For us the difficulty is that with React you need to let React control it's piece of the DOM. We have lots of jQuery UI components. For example, we use Select2. So let's say a dev tries to redo a jQuery heavy form in React. It's mostly fine but there's a Select2 component in there and some WYSIWYG jQuery plugin on a text area. You can't just initialize those with the React component because React will complain about jQuery touching the DOM it controls. So now you either have to find React versions of those jQuery components or properly wrap the jQuery components you have with React which, IMO, can be a bit funky and ends up feeling kind of wrong. Basically, you can end up down a rabbit hole. If you're intention is to truly modernize you're JS and your happy to rip out old jQuery plugins and make changes like that then it's fine. We just didn't have the dev budget to always be doing that.

</comment></comment></comment><comment><USER51> This comes from a well-known and respected thought leader. There are different types of thoughts, though. This is simply an observation:

> Don't @ me I'm not trying to start a controversy. I'm only stating an > observation.

[https://twitter.com/SaraSoueidan/status/1001189524477743105](https://twitter.com/SaraSoueidan/status/1001189524477743105)

React, like jQuery, could have done more to keep people from writing bad code. With React, they made the same mistake that Angular did, which was to impose strict rules on all developers. Vue, to its credit, doesn't make this mistake. It's much less opinionated about state management.

<comment><USER32> They should done more to keep people from writing bad code, they should have less rule.

What does that even mean?

<comment><USER51> In this case, doing more means responding to the real-world usage of React, and making it so that lifting state up isn't the only recommended option. Vue did this and is grabbing some market share from React. [https://reactjs.org/docs/lifting-state- up.html](https://reactjs.org/docs/lifting-state-up.html)

</comment></comment></comment><comment><USER52> Since early in my career when hiring I've found developers who only know 'jQuery / Angular / Vue / React' but not the underlying Javascript, I swear "x is the new y" is said every time a new framework gets 6 months into vogue.

<comment><USER53> _> Since early in my career when hiring I've found developers who only know 'jQuery / Angular / Vue / React' but not the underlying Javascript_

It's frightening, the degree to which many professional web app developers do not know the fundamentals of Javascript. Our technical interview starts out with ridiculously simple questions and gets progressively more difficult and esoteric. And a dismayingly high number of candidates don't get past the first couple of questions. And these are people with years of experience and at least some of the hot JS frameworks on their resume.

</comment></comment><comment><USER54> > React is a big commitment. I guess that's why I'm still struggling to > comprehend why so many organizations are so eager to take the sturdy, > foundational layer of the frontend stack and rewrite it all in a proprietary > format.

There's nothing proprietary about React. It's all open source. MIT licensed. If you don't like Facebook's implementation, there's like a dozen re- implementations. Hell, a modestly competent software developer could write his own implementation of React in a few days of work.

All else being equal, I'd say a React code base will be less of a maintenance hassle in the future, than the spaghetti mess you usually get when trying to write complex applications with jQuery (been there, done that).

</comment><comment><USER55> I like to shit on jQuery like anybody else, but it _did_ have its place in the world. It was totally abused by people, but that doesn't make jQuery _bad_ per se, any more than PHP or JavaScript is bad. Yes, I avoided using those things as much as I could, and I much prefer other tools, but they are tools nonetheless. Bad programmers and nontechnical people posing as programmers can abuse well-loved and efficient tools, too. Have you ever seen code written by a noob embedded "engineer" who decided to write their weekend side project in Golang? It's as much a fucking disaster as any of the bad PHP or jQuery stuff out there.

</comment><comment><USER56> JQuery is a great tool, it got a lot of buzz and people started to abusively use it out of its nominal scope. This does not say anything about jquery, only about people. React is having a lot of buzz, and the same abuses happen in places where it is nowhere needed. Same cause, same symptoms.

You can replace jquery/react with any technology or concept, OO programming, functional programming, MVC, blockchain, machine learning, and every technology or concept having its momentum is or will be misused in some way at some point.

This happened, is happening, and will always happen.

</comment><comment><USER57> I am learning to code and a newbe.

I think jQuery != react.

I do not understand, why experienced people like to compare jQuery with react when both the lib have different goal ? And show that jQuery is bad.

React can be used with jQuery for DOM manipulation. Described in react doc ([https://reactjs.org/docs/integrating-with-other- libraries.ht...](https://reactjs.org/docs/integrating-with-other- libraries.html#integrating-with-jquery-chosen-plugin)).

Shall I learn jQuery at all ? Please, guide me.

<comment><USER58> The comparison Sara made was that React can be overused just as jQuery was.

The problems with jQuery is that it's mostly a set of functions to simplify Ajax and DOM manipulation so it's not really helpful for the structure of an application.

React (and other frameworks surch as Angular, Ember and Vue), on the other hand, helps you to build reusable component which helps a lot to scale.

Also jQuery's golden age was when browser compatibility was a big issue, nowaday, most browsers behave properly.

There's no harm in learning jQuery, its interface is way more intuitive than native DOM apis. It could be a good idea to try and build a simple app with jQuery and see what are the pain points and then compare with a modern framework.

<comment><USER26> My only advice to people today would be to use one of the much smaller jquery- like libraries for DOM interaction/events and fetch (shimming ie11) instead of other wrappers.

</comment></comment></comment><comment><USER59> I wanted to try and address the points Brad makes and as well as clear up some of the misunderstandings in his post. Take a look [https://medium.com/@dmitrigrabov/react-is-not-the-new- jquery...](https://medium.com/@dmitrigrabov/react-is-not-the-new- jquery-e42a19f165f4)

</comment><comment><USER15> vue seem to be an evolution of react and angular.

it is as if some react developer sat down and said, "how can we make this even simpler so that even my grandson can do it."

i appreciate when we have guys like the authors of Vue come forward driving the community and taking web development to the next level giving us a more elegant solution.

<comment><USER26> More like a cousin... I see Vue as a nice component system for smaller applications, I don't think I'd want to build anything of even moderate complexity with it.

React is for building applications, especially with teams. Combined with redux and a handful of other pieces, it's very nice.

Angular, I don't get why anyone would choose it today (I've said it time and again).

<comment><USER15> I disagree. I would imo recommend you to switch to Vue if your app have gotten too big with React. As I said, Vue is more elegant and it improves the speed of development which also means less errors.

There are many big companies and startups who switched to Vue and loving it so I would say your point is moot.

<comment><USER26> Facebook is probably the single most interactive and complex application out there... it's using React. There's also more to it than just the UI portion... there's also state management, and the unidirectional workflow, that you don't get in nearly as consistent a way with Vue as say Redux.

Startups will use whatever is trendy. I'm unaware of any site the size of Walmart.com or twitter's mobile site, or Facebook that uses Vue.

Just because you disagree does not invalidate my point.

</comment></comment></comment></comment><comment><USER60> Nitpicks aside, it seems to me that React/Vue are only/mainly useful for two- way data binding. If it's just one-way binding (i.e. JSON to template), then jQuery with something like Handlebars will be just fine. Correct me if I've misunderstood.

<comment><USER61> React and Vue are immediate mode/declarative UI libs. Your code says "given the model/state, here's what I'd like the UI to look like right now", and they manage to mutate the DOM efficiently to achieve what you want.

jQuery and the plain DOM are retained mode APIs. You manipulate stateful objects to achieve your goals. It is ok for simple interactions, but it quickly becomes unmanageable for more complex apps.

</comment></comment><comment><USER62> Coming from a background of doing embedded Javascript work(not web) I found React surprisingly easy to work with and joy to write code in.

React feels like writing normal Javascript.

Vue is very easy to embed into existing web page but feels like learning a new DSL instead of regular Javascript.

</comment><comment><USER63> > I'm still struggling to comprehend why so many organizations are so eager to > take the sturdy, foundational layer of the frontend stack and rewrite it all > in a proprietary format.

it's about workforce and durability of the platform

</comment><comment><USER64> Mods, can we change the title? The current title was clearly chosen to be inflammatory. Meanwhile, the original title only mentions VueJS, not React: "Replacing jQuery With Vue.js: No Build Step Necessary"

</comment><comment><USER65> I don't really agree for various reasons. That said, I'm not a huge fan of react, but am stuck working with a few code bases that use it.

I prefer vue, but I dislike that it's essentially a one man show.

<comment><USER66> Vue isn't a one man show. It has a sizable team behind it.

<comment><USER46> > essentially

And when compared to React, he's absolutely right.

</comment></comment></comment><comment><USER67> Does React or other cool frameworks have alternatives to jQuery UI components or you need to build your own calendars,dropdowns, accordions.

<comment><USER68> React has everything (calendars, dropdowns, accordions and so on).

<comment><USER67> Can you link to the official repository? last time I checked you had to find something on github that mostly were incomplete and the best components were jQuery wrappers

</comment></comment></comment><comment><USER69> That's an incredible compliment.

</comment><comment> oh-kumudo jQuery in terms of popularity? I'd take it as a compliment.

</comment><comment><USER70> This guy is such a phony.

</comment><comment><USER71> The microwave oven is the new swiss army knife.</comment>


Sun Tries to Jump on iPhone Bandwagon with JPhone (2007) - <AUTHOR> http://www.roughlydrafted.com/RD/RDM.Tech.Q2.07/0ADA49EA-93A2-4960-BAAC-2257C9DBD32F.html <comment><AUTHOR> "For many applications, Java is a good choice. There's lots of proficient Java developers, and Sun has delivered regular advancements to its Java frameworks.

Where Java begins to lose value is when it is applied like Windows, as a layer pasted onto various hardware units with enough differences to create headaches but too few differences to stand out in the market place. Like Windows, J2ME only offers a pickle when consumers want a whole sandwich.

That's something that should have Sun sleepless: its wide but shallow position in mobiles is too similar to Microsoft's position as the vendor of a wide but shallow layer on PCs."

Ironic that Sun's language would live to capture a majority share of smartphones, but Sun would not!</comment>


Modula-2 Reloaded – A Modern Typesafe and Literate Programming Language - <AUTHOR> http://modula-2.info/m2r10/ <comment><USER2> The problem with Pascal/Wirthian family of languages in my opinon is that they are really scattered and it is somewhat difficult for an outsider to discover what is the currently alive variation. It doesn't help that the languages have been called Pascal, Modula, and Oberon with various prefixes and (version) numbers. Of course there are also various implementations of the different languages that also kinda live their own lives.

Does anyone know some comperehensive and up to date resource illustrating the whole language family?

<comment><USER3> > Does anyone know some comperehensive and up to date resource illustrating > the whole language family?

I am not an expert, but as someone that started coding in the 80's I have some of the knowledge myself. Some of these facts might be wrong.

Pascal:

Wirth created Pascal, the educational version, which was the target of the famous rant from Kernigan.

All Pascal vendors extended the language, the most common extensions for professional coding became the ISO Extended Pascal standard.

UCSD Pascal, Turbo Pascal, MacPascal and Quick Pascal were the most famous dialects.

Wirth collaborated with Apple in the design of Object Pascal, the original systems programming language for Mac OS. Those extensions were later on adopted by Borland for Turbo Pascal.

Given the influence of Turbo Pascal in the PC world, most Pascal vendors ignored the ISO Extended Pascal and tried to follow Turbo Pascal instead.

Object Pascal eventually became a synonym with Delphi.

Modula-2:

Wirth spends some time at Xerox PARC and gets to learn Mesa. When he returns to Zurich, he creates a systems programing language based on Mesa, without the issues that plagued Pascal and writes the Lillith OS in it.

Oberon:

Wirth returns to Xerox PARC, meanwhile Mesa has evolved into Cedar, a systems programming language with RC/GC, interactive debugger (REPL) among other features.

Again, when returning to Zurich, he creates Oberon (the language) and Oberon (the OS), following the features of Cedar.

Oberon gets used as workstation environment at ETHZ and as a means to teach OS programming at several european universities.

Wirth collaborates in the design of Oberon-2.

Other ETHZ collaborators create a startup to explore Oberon commerically and extend Oberon-2 further, thus creating Component Pascal.

Meanwhile the OS projects at ETHZ evolve the Oberon OS into Oberon System 3 with its gadgets systems, and evolve Oberon-2 into Active Oberon, which uses active objects as construct for parallel/concurrency programming.

Wirth already retired, decides to pursue his goals for a minimalist type safe systems programming language and designs Oberon-07.

Modula-3

The Xerox PARC designers behind Mesa and Cedar eventually join DEC when all falls apart and start designing Modula-2+, based on Modula-2.

With their learnings, they eventually create Modula-3 and the SPIN OS.

Unfortunately DEC gets bought by Compaq and Modula-3 related projects get canned.

<comment><USER4> Good summary. It's worth pointing out that Borland's Pascal had already diverged from other dialects, including Apple's, and when they tacked on the OO extensions from Wirth's ObjectPascal/MacApp, they diverged further.

MacApp is interesting in itself, but I'm not sure how much involvement Wirth had in its development. Delphi certainly owes a lot of its design to it, but nailed the visual UI builder in ways that MacApp didn't (and in a way that Interface Builder never has). Apple actually kept supporting and updating MacApp as late as 2002 (Photoshop was famously written in it) [1]; it's one of those beautiful niche things that eventually die, but keep a lot of people magically productive for a while (just like Delphi, coincidentally).

[1] [http://basalgangster.macgui.com/RetroMacComputing/The_Long_V...](http://basalgangster.macgui.com/RetroMacComputing/The_Long_View/Entries/2011/5/28_MacApp_- _evolution.html)

</comment></comment></comment><comment><USER5> Don't want to be off-topic but just wanted to share the info about a Modula-3 project hosted at [https://modula3.elegosoft.com/cm3/](https://modula3.elegosoft.com/cm3/)

They've also moved their sources to GitHub: [https://github.com/modula3/cm3](https://github.com/modula3/cm3)

<comment><USER6> I would dearly love to see a full-blown Modula-3 revival. It's one of these old, moribund languages that I have a huge soft spot for, especially since I'm a Pythonista and large parts of Python were lifted directly from Modula-3.

I also kind of have a thing for innovative languages that never really took off. Not just M3, but I'm also deeply fascinated by Algol 68.

<comment><USER5> I'm currently trying to compile the Modula-3 sources from GitHub. It's been a long time since I have done this.

I'm fighting with the compiler because it refuses to compile under x64 arch.

Also, one must use an older m3-compiler to compile the newer sources. _sigh_

I think I should write a little tutorial for us, 80/90es kids (and older) ... you know, nostalgia, mid-life-crisis etc. ;)

Regards,

</comment></comment></comment><comment><USER7> Dr. Dobb's Modula-2 article, ca. 1991 (I worked for Multiscope at the time):

[http://www.drdobbs.com/whats-new-with- modula-2/184408565](http://www.drdobbs.com/whats-new-with-modula-2/184408565)

</comment><comment><USER8> What's about the recent wave of Wirth's almost forgotten languages on HN? Pascal, Modula and Oberon and its silbings/etc were pretty niche last time I checked and most of their maintainer moved on.

<comment><USER9> I don't think Pascal is almost forgotten. Free Pascal ([http://www.freepascal.org](http://www.freepascal.org)) and Delphi ([http://www.embarcadero.com/products/delphi](http://www.embarcadero.com/products/delphi)) are both strong Object Pascal implementations. There's also Lazarus ([http://www.lazarus-ide.org/](http://www.lazarus-ide.org/)) which is a Delphi-like IDE and libraries for Free Pascal.

</comment></comment><comment><USER10> It's a good idea, 20 years too late. We should have had this in 1995. At this point, just getting programmers to write BEGIN and END will be a struggle.

Memory allocation needs to be addressed better. There seems to be a NEW, but no mechanism for deletion. (Wirth did that in Pascal. It didn't work out well.) Is this language garbage-collected?

For memory allocation, these are the known options:

\- Garbage collection (scripting languages, Go, LISP, etc.) - safe, but causes stalls.

\- Reference counting - (Python) safe, but can leak if you have loops. Usually adds overhead. May need a GC as a backup.

\- Single-ownership without borrow checking (C++11) - partially safe, errors can be detected at run time, but this is not guaranteed.

\- Single-ownership with borrow checking (Rust) - safe, complicated at compile time, but works.

\- Region allocation (Ada) - used in some real-time systems. Rare.

\- Manual deletion (C) - unsafe, leads to many bugs.

The manual option is probably unacceptable at this late date.

<comment><USER11> > Region allocation (Ada) - used in some real-time systems. Rare.

Equivalent to solving the halting problem unless you're writing toy software with extremely well-defined inputs and outputs. Good for device drivers, maybe, but not in the general case.

</comment></comment><comment><USER12> Whenever I read a Modula 2 source, I get the feeling the programmer is yelling at me.

<comment><USER10> The upper case keyword thing is annoying. In ALGOL-60, the keywords were supposed to be in lower case bold type. When algorithms were published in Comm. ACM, they were, but computers printers and displays of the time couldn't do that.

Displaying keywords in bold, and string constants in italics, would be a nice editor feature today. It would look better than syntax coloring. If you had an editor with enough smarts to line up the comments, you could even use variable-width fonts.

</comment></comment><comment><USER13> Can someone point me to the documentation for their cweb-equivalent (weave/tangle etc.)? Just interested if their definition of literate includes "macros", or just the semi-literate stuff you see more commonly these days (i.e. inverted comments, without restructuring).

Might also be just a fancy word for "we use begin/end, not braces".

</comment><comment><USER14> I wish they would show us some code.

<comment><USER15> Very generally, think pascalish golang. Eschews heavy abstraction, lower keyword count, green threads built in, modules instead of packages, no implicit type casts, copious compile errors. It did not have garbage collection, but I'm sure M2R10 will offer something in that area.

Topspeed made an awesome compiler and libraries for M2 back in the DOS days. The package came with a cute traffic simulator demo showing off the multitasking capabilities of M2. Logitech (yes, the mouse and keyboard guys) was another vendor back in the day, along with Stonybrook (sweet optimizations) and XDS, a Russian company which I believe wrote some M2 code for the Russian space program.

</comment></comment><comment><USER16> > [http://modula-2.info](http://modula-2.info)

> Warning: > include_once(/home/m2info/public_html/m2info/cookbook/rowspan55.php): failed > to open stream: No such file or directory in > /home/m2info/public_html/m2info/local/config.php on line 181

Looks really nice! Not to mention PASCAL-like semicolon-infected syntax with mindblowing features like dynamic memory allocation and CASE OF. Who would bother with this fossil crap?

<comment><USER15> Yeah, no generics either.

<comment><USER15> And no sense of humor either.</comment></comment></comment>


Ask HN: How many SMB SaaS companies are out there? - <AUTHOR> <comment><AUTHOR> Anyone has an idea? Angel.co has 10k listed, but I think many are not. What do you think the real number is?

<comment><USER2> I'd say there's way more than that - was a meetup and met plenty of folks operating SaaS companies whom I have never even heard of. Told me they were profitable as well.

My best guess would be to say potentially few hundred thousand worldwide.

<comment><AUTHOR> That much you think?

<comment><USER2> Yes, I think so. While some might not be classified as modern SaaS, I've seen some companies migrate over their desktop applications to offer SaaS options.

Given that there are tons of people I've spoken with who've never heard of AngelList, YC or TechCrunch and yet have profitable SaaS companies, I'd say there's a chance there could be at least 100,000 if we're to take in Europe, China, India etc.</comment></comment></comment></comment>


The iPhone and Google Reader hegemony - <AUTHOR> http://www.leancrew.com/all-this/2013/03/the-iphone-and-google-reader-hegemony/

<comment><USER2> Theoretically, if they did decide to charge a small usage fee, would people pay for the google service?

<comment><USER3> I'd pay $50 a year. Maybe more.

<comment><USER4> Agreed, it has proven its worth to me enough to easily justify a subscription service.</comment></comment></comment>


CEmu – TI-84 Plus/TI-83 Premium Calculator Emulator - <AUTHOR> https://github.com/MateoConLechuga/CEmu <comment><USER2> Can it play "drugwars"? [https://en.wikipedia.org/wiki/Drugwars](https://en.wikipedia.org/wiki/Drugwars)

<comment><USER3> Can it run linux?

<comment><USER4> Can it play Doom?

<comment><USER5> Doom existed for TI-85

[http://www.ticalc.org/pub/85/basic/games/](http://www.ticalc.org/pub/85/basic/games/)

</comment></comment></comment></comment><comment><USER6> Granted, this looks cool, and I'll show it to my kids, both of whom have TI graphing calculators (required for school). But from an educational standpoint, would we be better off saying goodbye to graphing calculators, and hello to something like jupyter? There are still some issues to deal with -- I would not try to use jupyter without a keyboard, and it doesn't run on Android or iOS right now. Surmounting these issues would be pretty cool.

<comment><USER5> I don't think we'd be better off. Other devices require the ability to manage distractions and interruptions, which is largely something society is still developing.

<comment><USER7> You still get some of that with existing graphing calculators though. There's a reason the #1 comment is about a TI-83+ game :)

<comment><USER5> Haha. Fair. I saw that a ti-83+ game 20 years ago was more than a novelty than it is today. It often was the only reasonably priced device like it that was completely portable.

</comment></comment></comment></comment><comment><USER8> It is almost insane that we still use TI-84's when we have all the power of smart phones in our pockets. I would love to see an app that can function as the calculator but also notify the teacher if it is backgrounded (to prevent illicit notes/internet access).

<comment><USER9> I just got a secondhand TI-84 on ebay for $20, the plan is to leave it in the woodshop for quick woodshoppy calcs. I never played with one before and was really impressed with what I got for $20.

<comment><USER10> For $20 it is impressive - the problem is when it's $120 and "required" for 13-14 year olds of all income levels.

<comment><USER11> Yeah, spending $90 for a TI-85 back in 1994 was pretty bad, but at least somewhat justifiable given the time. Paying the same today can only be the result of an abject market failure.

Related: [http://xkcd.com/768/](http://xkcd.com/768/)

</comment></comment></comment></comment><comment><USER12> Similar stuff exists for HP48G (et al) for all you RPN fans.

[http://www.hpcalc.org/hp48/pc/emulators/](http://www.hpcalc.org/hp48/pc/emulators/)

<comment><USER13> Oh, that's great! I miss my old HP-48, although I don't remember what flavour (S or G or whatever) it was. I also like very much that HP simply provides (or just links to, I guess) the software, rather than TI's approach of selling it.

<comment><USER14> If you have an Android device, the Droid48 app listed there (also at [1]) is worth a plug. A touch screen on a phone can't compete with the awesome tactile keypad those old calculators had, but at least the layout and operation are familiar and I've always got it with me.

[1] [https://play.google.com/store/apps/details?id=org.ab.x48](https://play.google.com/store/apps/details?id=org.ab.x48)

<comment><USER13> Great, thanks! Indeed, I meant to ask if, among the welter of options, there were any particular recommendations.

</comment></comment></comment></comment><comment><USER15> This is pretty neat. Just built using qmake on Windows, works smoothly.

The build folder on his personal site, what's up with that? There's no file extensions to the builds. [http://pimathbrainiac.me/CEmu/](http://pimathbrainiac.me/CEmu/)

</comment><comment><USER16> Ahhh this is just awesome. I spent the vast majority of high school chemistry class dinking around on my 83-Plus with whatever that flavor of BASIC was called. I would bet that if I were able to accurately measure 'minutes spent' in a variety of programming languages that this would make BASIC in my top 3.

Edit: Huh. Apparently that flavor was called TI-BASIC. [https://en.wikipedia.org/wiki/TI-BASIC](https://en.wikipedia.org/wiki/TI- BASIC)

</comment><comment><USER5> These devices were the equivalent of a smartphone in the 90's in a lot of ways.

I had a TI-85 in High School. Was the first calc to have a link cable to connect 2 calculators. Also had assembly programming capability thanks to an oversight that couldn't be taken away. This opened the door for things like doom, tetris and other games.

Got to build a serial port cable interface by cutting my wire in half, external storage devices for it, custom software.

Highlight for me was the programmability of it to write software for my high school courses, including math and chemistry formula sheet software. Calculus had to be done by hand but I had an app for testing various elements.

This type of development gave me a much deeper insight and grasp of math, formulas and how things worked and could be manipulated.

Surprisingly, teachers let me use my school apps on the tests because I built them myself and it needed an understanding of the concepts to build the software, and if I was going to risk my high school graduation on it, it was up to me.

It's kind of sad how much we could get done with constraints of limited hardware, and today's smart devices are making people less empowered by chasing novelty and distraction instead of solving their own problems.

</comment><comment><USER13> As someone who wants to use this in my classes: should I be worried about TI's legal department swooping in to shut this down? I don't know any of the legalities surrounding emulators in general, or TI's friendliness to outsiders doing this sort of work in particular.

The reason that I even think to worry about this is because TI sells their own emulator: [https://education.ti.com/en/us/products/computer_software/ti...](https://education.ti.com/en/us/products/computer_software/ti- smartview-software/ti-smartview-ce-emulator-software-for-the-ti-84-plus- family/tabs/overview) . From literally just glancing at the screenshot, CEmu's interface looks not dissimilar.

<comment><USER17> While IANAL, TI has not objected to emulators in the past; there are third- party freeware emulators available for all of their calculators (including the older 83/84 series, the 68K calculators, and the Nspire).

TI's legal department has tended to draw the line at two points: they don't like illegal copying of their ROMs (so, while they haven't objected to tools which pull a ROM off a real calculator you have in your physical possession, they will send takedown notices if you post those results publicly), and they've become pretty aggressive in working against anything that compromises the integrity of the OS on a physical calculator (because they don't want push-to-test features compromised). Just about anything else goes (and is occasionally encouraged).

<comment><USER18> Yup, TI's dealt with Android apps which emulate their calculators before, the rule of thumb is: You cannot provide the OS ROM, but you can offer the emulator if it requires their OS ROM to run. Theoretically, yes, so people have to get it from their own calculator.

The open secret though, is that TI offers the ROMs for their OS on their website for free download...

<comment><USER19> That's well within their rights so I really don't see the problem. Copyright basically means you get to have a say in who offers the stuff you built and TI requiring people to go through them for their ROMs makes perfect sense.

</comment></comment></comment></comment><comment><USER20> I was just looking at TI-83 / 84 calculators today because I saw that they used a Zilog Z80 chip and I wanted to try building the Z80 Forth from "Threaded Interpretive Languages" . I'll have to take a look at this and see if it would work for that.

</comment><comment><USER21> Feature request: make this a Retroarch core so I can play Drug Wars on my TV. Only sort-of joking.

</comment><comment><USER22> Fond memories... I tell people I started programming by typing BASIC apps out of magazines, but really it was probably much later writing a "casino app" (I remember having roulette and blackjack) and my own version of drugwars instead of paying attention in math class.

</comment><comment><USER23> See [http://fms.komkon.org/ATI85/](http://fms.komkon.org/ATI85/) for more.

Andie Graph is also a multi-TI emulator for Android Devices and Graph 89 for Android emulates the Motorola 68000 calculators.

</comment><comment><USER24> Is an emulator really that useful if you need a physical calculator to get a ROM off in the first place?</comment>


Little Graves in Georgia - <AUTHOR> http://www.oxfordamerican.org/magazine/item/717-little-graves-in-georgia <comment><USER2> Thanks for this. I really enjoyed his writing style as it reminds me of my own way of spinning tales. I read this story and his other story about Prince Albert Hunt's demise and found them entertaining and well-written.

Like the author, I have found myself browsing old 78's looking for musical treasures in old bookstores, yard sales and at places like Half Price Books.

Thanks for the entertaining reading.</comment>


BADA55: safe curves for elliptic-curve cryptography - <AUTHOR> http://safecurves.cr.yp.to/bada55.html

<comment><USER2> tl;dr: these are a joke on the NIST curves and the "verifiably random" way in which they were defined. While being safe curves, they've been tweaked to include the hex string "BADA55" in the "verifiably random" B constant derived using B=SHA3(seed). This demonstrates how other curve parameters could've been tweaked (by, say, the NSA) even in a "verifiably random" standard like the NIST curves.

At the same time these could conceivably serve as drop-in replacements for the NIST curves, but then people would have to recognize that djb is a BADA55.

</comment><comment><USER3> Hurrah! Curves that have a cofactor of 1. (One of the things I didn't like about DJB's speed hacked curve25519…)

Since they share the same field as the NIST curves it also means that software won't need any other code for these.

I do wish they'd strengthened their verifyably random practices beyond the brainpool technique, instead of just complaining about it. :)

For example, they took their non-public nothing up my sleeve choice (C), then hashed it (H(C)) and announced H(C) and this procedure to the world, then put H(C) in a Bitcoin transaction and took M to be the block hash of the block 100 after the block confirming it (because it takes 2^66 sha256 operations to retry a single Bitcoin block if you don't like its outcome, and 100 after ensures that there would be a race with the public network), then picked their random seed as HMAC(M||next-week's NIST random beacon,C) you'd have a random value who's selection someone could only compromise by either inverting H() or controlling the announcing team, and controlling the NIST beacon, and doing 2^66 sha256 * the number of retries on that step (or compromising sha256 to make bitcoin mining trivial).

<comment><USER4> Someone interested in a serious, rather than derisive, attempt at selecting good curves with cofactor 1 may want to look at the recent paper by Bos, Costello, Longa and Naehrig[0].

[0]: [http://eprint.iacr.org/2014/130](http://eprint.iacr.org/2014/130)

</comment></comment><comment><USER5> Talk about this:

video: [https://www.youtube.com/watch?v=maBOorEfOOk](https://www.youtube.com/watch?v=maBOorEfOOk) (audio kinda broken)

slides: [http://cr.yp.to/talks/2014.05.13/slides- dan+tanja-20140513-4...](http://cr.yp.to/talks/2014.05.13/slides- dan+tanja-20140513-4x3.pdf)

</comment><comment><USER6> Anybody knows how these stack up against Curve25519 (also by DJB)?

<comment><USER7> I can't tell if this is a serious new thing or if it's really intended to mock the "verifiably (pseudo)random" terminology, or both.

<comment><USER3> Appears to be both. They're drop in replacements. There are plenty of reasons to argue against DJB's other curves (need different code, have some 'insecure' characteristics that other curves have specifically designed out (non-prime order), don't use a 'verifiably random' initialization, require special key selection (high bit must be 1) to be compatible with DJB's software— which precludes some key generation techniques like the homorphic public derivation used by some Bitcoin software, etc.).

These alternatives check all the boxes I'm aware of... and it makes fun of the verifiably random procedure.

<comment><USER8> "Verifiably random" is a strategy to obtain the property Bernstein terms "rigidity". Curve25519 uses a different strategy; from safecurves:

 _Prime chosen "as close as possible to a power of 2" for efficiency reasons ("save time in field operations"). Prime chosen "slightly below 32k bits, for some k" for efficiency reasons ("no serious concerns regarding wasted space"). k=8 chosen for "a comfortable security level". 2^255-19 chosen above 2^255+95, 2^255-31, 2^254+79, 2^253+51, 2^253+39 "because 19 is smaller than 31, 39, 51, 79, 95". Montgomery curve shape y^2=x^3+Ax^2+x chosen for efficiency ("to allow extremely fast x-coordinate point operations"). (A-2)/4 selected as a small integer for efficiency ("to speed up the multiplication by (A-2)/4"). Curve and twist orders required to be {4_prime,8 _prime} for security ( "protect against various attacks ... here 4, 8 are minimal"). Primes required to be above 2^252 for security ("theoretical possibility of a user's secret key matching the prime"), ruling out A=358990 and A=464586. A=486662 chosen as smallest positive integer meeting these requirements_

Each of the parameters of the curve has a straightforward explanation; they're explainable from first-principles.

I'm not sure what the "non-prime order" objection you're describing is.

The leading 1-bit on the key prevents a potential timing attack.

The rest of your objections seem to boil down to "Curve25519 isn't a NIST curve, and NIST curve software doesn't naturally support it". That is indeed a valid objection if the only curve software you can use supports only the NIST curves.

<comment><USER3> > I'm not sure what the "non-prime order" objection you're describing is.

Curve25519 has a cofactor of 8— its order is prime*8. This directly reduces rho security by about 1.5 bits, and since many discrete log attacks exploit a composite order for further speed up almost all other requirement sets for curve selection (including NIST and Brainpool) have required curves to have a cofactor of 1 in an abundance of caution (a small cofactor isn't know to create weakness right now, except via the direct reduction against rho attacks, but its obviously prudent to ask the cofactor be 1 out of the same kind of caution that suggests building systems which are twist secure or not using fields of small characteristic).

> The leading 1-bit on the key prevents a potential timing attack.

Yes, it does. But the timing attack can be prevented another way (e.g. always doing that outer loop and throwing away the result is one example— using a bit interleaved precomputed table is another) but that is slower. The consequence here is that existing curve25519 implementations are incompatible with some very useful forms of key generation. The effect is that implementations must sacrifice either security (by not being able to use public key derivation techniques that improve security) or compatibility (by ending up with private keys that don't have the high bit set and being unable to use the widely distributed fast curve25519 code).

WRT the compatibility— it's not just about "only use the NIST curves", many things already have fast, well tested and reviewed constant time code for doing operations over the fields used by the NIST curves. The BADA55 curves curves instead would just be constant changes. It's a much smaller change than changing to something that uses a totally different field. This may be a consideration for some.

In the same way that VPR managed to find a very simple sounding transcendental constant that achieved the BADASS property the same sort of attack could potentially be employed against DJB's design criteria (though, admittedly, not a one in a million one). Not that I'm suggesting those curves are rigged, but several of his mandated criteria are very different than ones commonly used for purely performance reasons. At the same time DJB doesn't like SECP256k1 which has an almost identical design strategy because it achieved performance in a different way (though also a way that gives up about 1.5 bits of rho security).

<comment><USER8> Aren't you oversimplifying here, like, a _lot_? All things being equal, you want a cofactor of 1. But all things aren't equal; you also want a performant curve, which is hard to get with a curve with a cofactor of 1.

What you actually care about is the attacker effort using Pollard's Rho taking into account the whole curve and all its parameters. Which, on Curve25519, is 2^126; that's not "spinal tap grade security", but the dial there is turned at least u to "10".

More importantly: this isn't how curve software is actually going to be attacked. NIST P-224 twist security is much more important than whether you have 2^126 or 2^259 vs. Rho. This cofactor discussion seems to me a little like debating whether attackers are going to factor RSA-3072 or RSA-4096.

(Note that Hamburg's "Goldilocks" curve has a cofactor of 4.)

I'm not sure I want to dig into the "rigidity" of BADA55 vs. SECP256k1, except to say that the NIST p- curves have a much bigger rigidity flaw than the other 3 options we're discussing.

</comment></comment></comment></comment></comment></comment><comment><USER9> Funny, the hashes all start with 0xBADA55... :)</comment>


Ask HN: where do you backup a ton of photos? - <AUTHOR> For years I've been dealing with the issue of wanting to backup large quantities of photos somewhere safe. I have several terabytes of them, either shot by me or passed down to me by my dad and friends.
I've been migrating from hard drive to hard drive for a long time, occasional drive failures here and there, and it's been pretty much a waste of time. I'd much rather put it up somewhere that scales infinitely, is properly redundant, and still gives me the ability to browse through the photos if I'm looking for something specific.
Dropbox is too expensive for the size I'm talking about. Google Photos tries too hard to push the G+ thing on me, which I don't care about, and Flickr offers no API to work with large sets of assets as far as I can tell.
There's Amazon's S3 and Glacier, which seem pretty reasonable for the price, and do have plenty of APIs, but as far as I can tell they don't really offer a way to nicely browse the images. Perhaps someone built a UI wrapper on top of that, wouldn't surprise me.
I can always setup a home NAS, maybe get 8TB in Raid 10, but I'm still concerned that these disks will eventually die and I'll still risk losing everything. Maybe I'm paranoid.
What are my other options? Am I missing something here? There's no way professional photographers don't deal with this issue every single day, so it must have been solved already. <comment><USER2> Anywhere but "the cloud."

I desire actual control over my backups and who might have access to them. I spend money on redundant external drives, and spare parts for said drives. I keep track of the age of my drives, the degree of usage/wear-and-tear they're subjected to, their warranties, and failure rates for sister drives of same make and model purchased at the same time.

I don't worry about having a convenient interface to facilitate browsing through my backups. All I want is a bulk file system with no meta-data (no xml files, no db files). When forced to resort to restoring from backup, one is already faced with degrees of inconvenience. If the backup media is more convenient than the normal general-purpose everyday-use storage, then why is the backup media playing second banana to the day-to-day system?

<comment><USER3> Do you rotate your drives out to multiple secure storage facilitates? Do you have a plans against theft and fire?

You can have all the redundant copies in the world, but one earthquake won't respect your availability requirements.

<comment><USER4> So store the NAS in another city.

</comment></comment></comment><comment><USER5> I would recommend keeping:

1\. A local backup copy on external drives.

2\. Backup to crashplan (change settings so if a file is removed locally they keep the copy in the cloud).

3\. Burn a copy to DVD (incrementally as they are taken off your cameras/phone) and store those offsite at your parents or a friends house.

I usually create DVDs by month for images . . . so you can track down images easier by date and then also have a best of each year on a DVD.

Over the years though a lot of photos are taken . . . at some point I expect you'll reach the age where it's physically impossible to even view all the photos you've taken . . . but it will be nice for kids/grand kids in the future to be able to browse through 75 years of grand pa and great grand pa's photos and see what he was up to . . . if the data survives through the generations . . . teach your kids about backups and passing down data . . .

</comment><comment><USER6> It's not photo-oriented and you won't be able to browse your photos on-line. But we are building a secure long-term personal digital archive at [http://longaccess.com/](http://longaccess.com/)

We would appreciate any feedback, as you are obviously someone that could use our service once (very soon) it's commercially available.

</comment><comment><USER7> To backup 1TB on Soft RAID-ed fast storage on your own dedicated server (no cloud) will cost you approx $500/yr, all inclusive with no S3 pay-per-byte in- and-out bullshit. If that budget will work for you - then I could send you the link.

</comment><comment><USER8> Crashplan might be worth checking put. You still need the NAS backup, but I have found Crashplan is good for the offsite aspect of it.

</comment><comment><USER9> How much would you pay for a nice UI wrapper, and the ability to designate glacier photos vs. S3 photos?

</comment><comment><USER7> PS: SmugMug seems to offer something that might help you.</comment>


Andreessen Horowitz's talent agency model - <AUTHOR> http://blogs.wsj.com/venturecapital/2011/01/21/why-andreessen-horowitz-models-itself-after-a-hollywood-talent-agency/

<comment><USER2> This is an interesting albeit, scary idea.

I can see the benefits of such a company for a select group of individuals. However, the rest of the population may be treated as second-rate professionals; like the way it is with Hollywood. Most "talent" in Hollywood are not the best and brightest. They're either well connected or extremely lucky (with very few exceptions).

If an idea like this were to be successful, I think we'd see a flood of talented people more interested in being stars than being productive.

But, then again, maybe we're already there.

<comment><AUTHOR> I've seen this happen in smaller markets with one dominant VC... Thankfully in the Valley we're a long ways from a company being DOA without AH as an investor.

</comment></comment><comment><USER3> Having talked a couple of times to various members of Andreessen Horowitz's team, I'm thoroughly impressed with they way they are approaching VC in the Valley. They are very much taking a long term approach to things, and they have some really good people on their team.

Kudos to them for innovating.

<comment><USER4> [http://www.endeavor.org/blog/interview-wgina-bianchini- new-m...](http://www.endeavor.org/blog/interview-wgina-bianchini-new-member- of-gab)

"Entrepreneurs in Residence" is fantastic.

</comment></comment><comment><USER5> "Groupon looked like a very high valuation," Horowitz said, "but any investment in a great company at any stage is almost always a good investment."

I don't think I'd want to hear that statement come from someone who is investing my money.

<comment><USER6> You should be comfortable hearing a sentence such as that. Horowitz is clearly generalizing, but a _great_ company will always make a return on investment. Obviously in this particular case Groupon is going to give investors a smaller return now than it would have 6 months ago, but it's still a winning strategy. Great companies keep growing - which is more than a good reason to invest.

<comment><USER7> Depends. Even great companies can be too expensive. But the stage doesn't matter, like Horowitz said.</comment></comment></comment>


Ask HN: Why should I use OpenID? - <AUTHOR>

I know this is going to be controversial and I know I may have missed something, but here goes...
As a website owner, why should I allow OpenID logins on my site? I see one major disadvantage: I don't have any contact info for my users. This breaks the primary link between me and my users.
I can see OpenID being used for many scenarios, but I don't think it's the ultimate cure of login cancer it's hyped up to be.
Again, I'm all ears to learning something new here.
Thanks, Pierre <comment><USER2> OpenID is not a replacement for your users table. The first time someone logs in with an OpenID you haven't seen before, there's nothing to stop you from asking them for their e-mail address (you can even send them a challenge e-mail if you want to be sure). All OpenID really does is provides your users with an alternative to setting up Yet Another username and password just for your site. It also lets people opt-in to correlate their accounts across multiple services, which is useful for both you and for them.

If OpenID meant giving up the user database (the crown jewels of any site) it wouldn't have a chance of being adopted by anyone.

<comment><AUTHOR> So why ask the user to enter an OpenID login and then follow up with an email address? An analogy: you're filling out a form and you think you're done because the front page is short and sweet. Then Mr Evil Banker Man tells you, actually, you missed the back side and that's long and convoluted.

That's happened to me and I always felt betrayed, as if being led into something naughty and the person doing the leading is hiding something.

In short, there is something stopping me from asking for the email address, and that's usability and trust building.

</comment></comment><comment><USER3> What percentage of non-techies has even heard of OpenID?

What is important to the computer world is different from what most of the rest of the world values.

For me, the ultimate answer would depend on how computer-savvy my intended audience is and how much extra effort is necessary to support it.

<comment><USER4> You could have said the exact same thing about, say, the Internet 20 years ago.

I'm not claiming OpenID is as important as the internet, but just because average people don't know about it doesn't mean its not important or won't be important in the future.

</comment></comment><comment><USER5> Well it is not too difficult to implement and it can speed up the registration flow for new users, which should always be a good thing.

OpenID is still getting better though. Yahoo! just became an OpenID provider which should help it catch on. And the ClickPass guys have built a great tool on top of it as well. So it looks right now like OpenID will survive and become better in time and perhaps achieve the goal of replacing the registration flow.

So while you say it is not the cure right now, I think that if you give it enough time it possibly could become one.

</comment><comment><USER6> As a website owner, OpenID nets your site security. Most people reuse the same small set of usernames and passwords. A not-so-small number of sites store cleartext passwords; they can even mail it back to you. Regardless how well you execute security, a breach at any of these sites compromises security across many user accounts across many sites.

Several weeks ago a Web 2.0 company launched a Gmail backup app that asked for addresses and passwords, which at least 1777 unwitting folks provided. In addition to backing up Gmail as expected, the app also socked away the address and password combo. When the scheme was exposed, the company said debugging code inadvertently made it to production. <http://codinghorror.com/blog/archives/001072.html>

I can see scenarios where the government may be the least of our worries. Much more likely are significant others' jealous exes who are also system administrators, and other real or potential enemies. The sooner we move away from passwords and other shared-secret systems, the safer we'll be.

</comment><comment><USER7> Alternative question: why shouldn't I use OpenID?

What are the common concerns, and which are valid/invalid?

<comment><USER8> As far as I can tell, the biggest concern is that OpenID makes phishing easier and more valuable. When the same user ID and password open all your accounts, one mistake compromises everything. Let's say clickpass gets huge, and someone forges a malicious clickpass-lookalike widget. They spread it around the net. Any password they steal gets them in to all clickpass-enabled accounts.

<comment><USER6> The weakness of the above argument: Why would site-owners install an untrusted Clickpass widget spread around the net but not from Clickpass itself?

I can see how some users might fail to recognize a Clickpass or OpenID url and give their login credentials to a fraudulent site, but no worse than password management, OpenID requires folks be on guard against phishing.

<comment><USER8> It's the same problem as current passwords, but with higher consequences for those who don't use the same userid and password across sites.

</comment></comment></comment></comment><comment><USER6> The reliably thoughtful Chris Messina just posted on the benefits and costs of OpenID, partly in response to a decision by linkmarking site <http://Ma.gnolia.com> to stop accepting traditional address and password registrations in favor of OpenID only. [http://FactoryJoe.com/blog/2008/03/30/magnolia-moves-to- open...](http://FactoryJoe.com/blog/2008/03/30/magnolia-moves-to-openid-only- sign-ups/)

In the cat and mouse game between site owners and spammers, data on recent Ma.gnolia registrations showed an overwhelming number of spammers have begun using automated tools to proxy Captcha and create traditional address and password logins. For now, OpenID encumbers them by requiring presumably more valuable credentials.

</comment><comment><USER9> It would've been nice if OpenID provided a way for Web sites to contact users without knowing their email address. This way, the Web site owner will not to put up an annoying page asking for an email address, and the user has control over who's allowed to contact them through their settings with their OpenID provider.

Facebook is hopeing to be such provider and they're giving these nice features. There are a few Web sites that allow you to login to using your Facebook cridentials, and by doing so they can email you without knowing your email address. And, Facebook allows you to optout at any time and they also measure how many people opt out and put a cap on the offending Web sites if they start to spam people. It's a nice system, except for the vendor lockin part.

</comment><comment><USER10> As a web site owner, I've always seen openid as a nice thing to have. It was #40 on my list. Then clickpass showed up and it moved to #3. Last week I implemented it. I integrate with disqus. Log in to either disqus or ourdoings via clickpass and logging into the other site is just 1 click. It's very slick. If people do adopt clickpass they'll be reminded that I'm one of "your sites" and come back.

</comment><comment><USER11> To re-emphasize/clarify previous statements, OpenID doesn't require visitors to know about OpenID. A website can offer a registration/login process that requires nothing more than the visitor's AIM screen name, or livejournal account. (See example <http://nshrine.com/u/registerhere.html> )

This not only eases the yet-another-name-and-password problem, but it also allows services complimentary to existing services to ease information sharing. For instance, OpenSocial functionality will be a breeze if accounts are already using an OpenSocial provider's OpenID.

</comment><comment><USER12> It's good business to be friendly to your users. Also, for people who already use OpenID, having OpenID on your site lowers the barrier for entry.

<comment><USER13> _for people who already use OpenID_

That's one thing I never got about OpenID and its ilk, though. "We'll fix the way logins work! Just sign up for _one more thing_ and then sites that support this will be accessible." Why is this the cure for sign-ups? Yet one more service to fill out some credentials for when sites do not universally accept it? If the latter part were true, then sure, but in the meantime I don't really see the point.

I am ignorant of the major benefits of OpenID, so if anyone could enlighten me, I'd be happy.

Edit: this post helps <http://news.ycombinator.com/item?id=151376>

<comment><USER6> America Online + AIM, Yahoo, Flickr, Livejournal, Vox, Typepad/key, Google, and enough widely-used sites, plus Drupal, Wordpress, and other widely-used platforms provide OpenID that very few users would need to create yet another login/password. Those already with many logins would likely already have multiple identity providers from which to choose. Those with few logins would presumably have less of an issue.

See <http://wiki.openid.net/OpenIDServers> for a much larger (but nowhere near comprehensive) list of providers.

</comment></comment></comment><comment><USER14> For those who have already added OpenID support, or something like Clickpass - what is the adoption rate like? How many people use it versus the traditional login?

I would be surprised if it's as high as 10% even for a tech-savvy site like News.YC, but I'm not basing that on any facts. Am I way off?

</comment><comment><USER10> Given all the well-thought-out objections on this thread, I've decided to back out of the OpenID support I recently implemented. Details here:

<http://ourdoings.com/2008-04-01>

</comment><comment><USER15> You would just have to assess your target audience and decide whether the cost of developing support for OpenID are outweighed by the benefits of allowing a portion of your users the convenience.

I see little reason to implement it if your most of your users will be unaware of it. On the other hand though, having the support for it (and similar providers) may help you attract those users who do use them. If you do implement support though, make sure it doesn't obfuscate your registration and login processes.

</comment><comment><USER16> You shouldn't.

</comment><comment><USER17> Good question! I mean that in the sense that I also have wondered about what I should do.

From what I've read and researched (based on the answers here), Clickpass is the best way to go.

It's also got PG's support, so it can't be all bad. :-)</comment>


Bash Initialisation Files - <AUTHOR> http://www.solipsys.co.uk/new/BashInitialisationFiles.html?HN0811

<comment><AUTHOR> Prompted to submit this because of this item:

<http://news.ycombinator.com/item?id=4369485>

</comment><comment><USER2> This is a great start but I'd love to know e.g. exactly what qualifies as a login shell and what calls the shell with these various arguments.

<comment><USER3> Any shell started with a minus as the first character of argv[0] is a login shell e.g. "-bash" is a login shell.

Many things start your shell this way:

      * the "login" command
        e.g. logging on an a virtual console
      * "su -"
      * "sshd"
        e.g. ssh <hostname>
      * xterms, depending on the settings
        e.g. the original xterm if you run "xterm -ls"
        or you run "xterm" with "xterm*loginShell: true"
        in your ".Xdefaults" or ".Xresources"
      * some X initialization scripts,
        e.g. when logging in to a "Default" session via gdm or kdm
       (how exactly this works depends on your distribution
        some explicitly source .profile instead)

With "bash" you can also manually create a login shell using "bash -l" or "bash --login".

<comment><USER4> Also sudo.

        $ sudo -i
        # tr \\0 \\n </proc/$$/cmdline
        -bash
        #

</comment></comment></comment><comment><USER5> It would be very cool if there was a similar graph for the entire boot process: from grub to init to rc.d/systemd to login to bash.

<comment><USER6> You can use

        systemctl dot

It shows the dependency graph of your unit files.

<comment><USER7> It should be noted this is for systems that use Systemd, which as far as I'm aware of, is only Fedora at this stage.

<comment><USER8> OpenSuse also ships with systemd per default. Other distributions like Arch or Debian support systemd as well.

<http://www.bootchart.org/> is also quite interesting to understand the boot process better and profile it.

<comment><USER7> Ah, I had a suspicion OpenSuse would, as it follows Fedora quite closely. Bootchart is also quite interesting.

</comment></comment></comment></comment></comment><comment><USER9> I'm with Henry Spencer on this.

"Those who don't understand Unix are condemned to reinvent it, poorly."

</comment><comment><USER10> If you want to understand this more, read "Bash Startup Files" and "Interactive Shells" from the Bash Reference Manual.

[http://www.gnu.org/software/bash/manual/bashref.html#Bash- St...](http://www.gnu.org/software/bash/manual/bashref.html#Bash-Startup- Files)

[http://www.gnu.org/software/bash/manual/bashref.html#Interac...](http://www.gnu.org/software/bash/manual/bashref.html#Interactive- Shells)

</comment><comment><USER11> So where does Git Bash for Windows fall into here?</comment>


DigitalOcean - Transparency Regarding Data Security - <AUTHOR> https://digitalocean.com/blog_posts/transparency-regarding-data-security?1 <comment><USER2> _At no time was customer data "leaked" between accounts. This would require that a user not scrub their volume after destroying their server; in this instance data would be recoverable and should be considered not sensitive._

Is it just me, or is this contradictory? "Data wasn't leaked.. but if it was it was because you didn't check scrub, so it must not have been important." These are two completely different things. Even if the data was not sensitive, it could still be leaked between accounts (which is what happened here).

Kudos for committing to fixing the problem though.

<comment><USER3> A lot of the talk was theoretical and the examples run were I think all within a user's own space.

If not though, then you're absolutely right that those are contradictory. If, even during disclosure, one user's data was made available to another user, that constitutes a data leak.

<comment><USER2> [https://github.com/fog/fog/issues/2525](https://github.com/fog/fog/issues/2525)

[https://f.cloud.github.com/assets/408977/1820859/8658298e-71...](https://f.cloud.github.com/assets/408977/1820859/8658298e-710e-11e3-867a-f3506838146a.png)

      These are some of the strings I pulled off the root blockdev
      - I have no such /var/deploy/chegou, or any of these files. I was
      able to recover someone else's webserver logs from yesterday, as well.

<comment><USER3> Yep, in that case that's absolutely a leak of user data.

The blog post is factually incorrect on that point, what a shame.

<comment><USER4> Right now, as far as I can tell, that's speculative on both sides. Simply not enough evidence to say without corroboration that it's factually incorrect.

</comment></comment></comment></comment></comment><comment><USER5> * Our first and immediate update is to ensure that a clean system is provided during creates, regardless of what method was taken for initiating a destroy [...] The scrub feature will remain, allowing customers to take an extra level of precaution if they choose to scrub the data after the delete.

What is a "clean system", if not a scrubbed one? And if they're scrubbing during create, why leave the scrub option in during destroy? I have to assume that when they say "clean system" they _don 't_ mean a scrubbed one, and that worries me.

If, as they said, their reason for not scrubbing is because of customers creating and destroying a lot of volumes during the onboarding process, then it seems to me the best solution is one that I believe was suggested in the previous thread. Namely, scrub a volume always whenever it's being used by a new customer. But if the volume is being reused by the same customer, don't bother scrubbing (unless requested), as presumably there are no concerns about leaking information from a user back to the same user.

</comment><comment><USER6> Previous thread: [https://news.ycombinator.com/item?id=6986155](https://news.ycombinator.com/item?id=6986155)

</comment><comment><USER7> Why not use whole disk encryption in the hypervisor and switch the key between accounts?

</comment><comment><USER3> I've seen the TRIM recommendation pop up a few times, and never with a reply from DO - is this probably how they're going to handle this, or is there a possible reason for not using TRIM?

<comment><USER2> TRIM is equivalent to 'mark as free'. there's no guarantee it will zero the data, and whether it is zero'd depends on the manufacturer/model of the drive.

If that's how they implement it, then I look forward to reading their future security advisory.

<comment><USER3> Ah yes, I'm not super familiar with the terminology, a sibling comment to yours specifies that you'd need to use zdat (zero after TRIM) for what I'm talking about to be effective.

</comment></comment></comment><comment><USER8> And they forgot to add a date on their security updates. How are you supposed to know when issues are discovered and subsequently addressed?

<comment><USER9> The linked blog post says "Posted on December 30th, 2013", were you referring to the blog post or something else?</comment></comment>


PLP Podcast S2 Ep1: Guest- Eoghan McCabe of Intercom - <AUTHOR> https://soapboxhq.com/blog/management-skills/people-leading-people-eoghan-mccabe-intercom <comment><USER2> Love this snippet: "I try to show gratitude when it is appropriate, and it's always appropriate, but you know when people do particularly good work I want to make sure that that's recognized."

Especially when he says "it's always appropriate". As a leader and professional, it's SO important to make recognition a key component of your culture. As a leader of an organization, you're a big part of what shapes the culture and by instilling behaviors that bring your team up, you're fostering a more positive and collaborative company culture.</comment>


Chinese satellite sends 'hack-proof' message - <AUTHOR> http://www.bbc.com/news/technology-40885723 <comment><USER2> Doesn't this really create a message where tampering is evident and not hack- proof or have I misunderstood?

</comment><comment><USER3> this is actually sequel to those sensationalist 'teleportation' articles. If you expected they will develop to teleportation of humans you'd been wrong.</comment>


T. Greg Doucette on reforming the police - <AUTHOR> https://threadreaderapp.com/thread/1266053291684827138.html <comment><USER2> An excellent Qualified Immunity explainer:

[https://theappeal.org/qualified-immunity- explained/](https://theappeal.org/qualified-immunity-explained/)</comment>