Show HN: A pipelined RISC-V processor written in VHDL - <AUTHOR> https://github.com/inforichland/freezing-spice <comment><USER2> Nice! I wrote a 5-stage pipelined RISC MIPS processor in SystemVerilog last semester, in one day, drunk as HELL, but hey, it worked amazingly well. Thank goodness they didn't ask for branch prediction.

</comment><comment><USER3> Does it do anything different or better than Rocket (or Sodor) that would be notable? Why VHDL instead of the more conventional (heh, for this ISA) Chisel? Would be good to see some notes about architecture in the README just to tell me what I'm looking at.

<comment><AUTHOR> I am still leery of the "unconventional" HDLs. I don't really see many of them as much of an improvement over say, VHDL-2008; you get records and functions and instantiation is not as verbose. Yes, the language is a little wordy but it's well proven and I already know it; and many other people know as well, so they can read it and understand it better w/o learning a new language.

<comment><USER4> Higher level generator HDLs shine when you want something heavily parametric. VHDL and Verilog code generation features are way too weak, so having a higher level meta-language helps a lot.

</comment></comment></comment><comment><USER5> Firstly, I commend you on your work.

Second, I looked into your tests directory and from first impressions there's not much there. What is there is kinda messy and not conducive to thorough testing.

If I could make a suggestion: you should look at reusing the work of others. You are in the lucky position where some work has been done for you! There's a massive amount of tests for RISC-V that already exist at [https://github.com/riscv/riscv-tests](https://github.com/riscv/riscv-tests) (by weird coincidence someone posted links about this in another thread a few days ago!)

If I were you I would be going through that stuff to try figure out how to get those tests running in my environment. E.g. You have to compile a test and create a mechanism to load the binary into your testbench memory or whatever.

<comment><USER6> "E.g. You have to compile a test and create a mechanism to load the binary into your testbench memory or whatever."

God, that's always the hardest part about these things. The core takes you a weekend, but the connection to the outside world takes forever.

<comment><USER5> I think I am one of those who would do it the other way around, from the outside inwards connecting to the outside world first. I already know ALL the I/O for the core is somewhere in the RISC-V design code (exact signal names etc). It has to be in Chisel or something.

I would translate that to VHDL to get my ports. It becomes a stub to build my core-level testbench on. If I can mirror their test environment, I at least have a start point. Maybe I could even reuse their testbench somehow.

Then I'd start duplicating the sub modules and their interconnections in the core. And so on.

Do the tough stuff first then enjoy things getting easier as I go along hopefully!

</comment></comment></comment><comment><USER7> One thing I've wondered about recent ISAs is regarding split register files. Since most CPUs are single-chip implementations these days, why not have integer, fp, and vector registers unified at the ISA level to allow different implementation points and less state spilling/loading during context switches:

(1) High performance implementations use register renaming anyway, so they can easily use a split register file internally without exposing it at the ISA level.

(2) Low power implementations can use a single register file (at the cost of fewer I/O ports).

This would also mean that when switching threads, only a little bit more state than the vector unit registers would need to be stored and loaded.

<comment><USER6> The RISC-V ISA manual covers your question on page 37 (riscv.org).

> "a split organization increases the total number of registers accessible > with a given instruction width, simplifies provision of enough regfile ports > for wide superscalar issue, supports decoupled floating-point unit > architectures, and simplifies use of internal floating-point encoding > techniques. Compiler support and calling conventions for split register file > architectures are well understood, and using dirty bits on floating-point > register file state can reduce context-switch overhead."

(1) Not really. It's easy to go from ISA says "split" and your processor uses "unified", but it's much harder to go the other way with it... the whole point of a unified ISA register file is you can trivially write to a "FP" register and then read it for a "integer" ALU operation. Now you've made that very hard if you try to internally split the RF.

</comment></comment><comment><USER8> MMU?

I see one place seemingly using RISC-V with an MMU in the classic desktop PowerPC style (Linus Torvalds posted a great rant about the stupidity of that MMU) and another place that is seemingly using RISC-V with an MMU that is very much like x86 (the paging part, obviously no segmentation) but with distinct rwx.

Which is it? Did this not get specified? Constantly changing the MMU greatly hurt 32-bit SPARC and PowerPC.

FWIW, this is good: Bits 0..11 direct mapped, bits 12..29 are x86-style page table tree node indexes that are hardware-walked, and bits 30..63 are software-filled like MIPS. (a forest of trees) In the low bits of the bottom level you get: can read, did read, can write, did write, can execute, did execute, user/super (exclusive), type ram/framebuffer/mmio/pte (two bits), reserved, and validity. The "did foo" bits on PTE pages do get updated.

<comment><USER6> You can find your answers in the Privileged ISA spec ([http://riscv.org/download.html#tab_spec_privileged_isa](http://riscv.org/download.html#tab_spec_privileged_isa)).

Of course, it's an open ISA, so you can do whatever you want. The style of virtual memory you choose to use will depend on the target application.

<comment><USER8> Thanks. The following concerns paging, not the base/limit system:

From a security and reliability perspective, I'm saddened to see that rwx got supported while --x did not get supported. That is backwards. Having to change permissions after code modification is not bad; this provides a convenient point for cache flushing and ASLR-enforced address changes. Preventing executable code from being misused as data is valuable.

I'm also saddened to see that user access implies supervisor access. This too is exactly backwards; nothing should be both user and supervisor accessible. Given that data access can be performed at a less-privileged level by setting MPRV=1, the ability of the supervisor to access user pages normally is especially strange.

Lack of distinct did-execute and did-read bits is mildly annoying. If a page is marked as being accessed and executable, one must assume that it is now in __BOTH __the instruction cache and the data cache.

I have mixed feelings about having page frame numbers shifted over by two bits. The win is Sv32 getting a reach of 16 GiB. I suppose this is worth the minor annoyance when debugging OS kernel code.

Other than that, I like it. It's certainly sane. The traditional page table is pretty good for the middle bits of the virtual address. I think it is less good for the upper bits due to ASLR, and I hate to see anything that encourages a failure to use all 64 bits of the virtual address space.

<comment><USER6> You should read through the RISCV mailing list archives ([https://lists.riscv.org/lists/](https://lists.riscv.org/lists/)) for discussions on these topics, and contribute your own thoughts if they haven't been covered. The ISA-dev list should be the most relevant. They have thought very carefully about these things and I'm sure they'd appreciate additional feedback on the topic.

</comment></comment></comment></comment><comment><USER9> Interrupts / Exceptions are probably the most difficult piece and may force a complete redesign. Since they are not done yet, I'd wait a little bit longer...

<comment><USER6> It's actually really pretty easy to do. I put together a handful of different RISC-V cores that all implement the privileged/supervisor spec ([https://github.com/ucb-bar/riscv- sodor/blob/master/src/rv32_...](https://github.com/ucb-bar/riscv- sodor/blob/master/src/rv32_1stage/cpath.scala)).

Basically, detect a few cases in Decode, pass the rest of the instruction down the pipeline to the commit(memory) stage, and let the commit stage detect exceptions and redirect the PC as required.

<comment><AUTHOR> Exactly, that's how I would (hopefully will soon) implement it as well; it takes a few extra cycles but avoids extra overhead.

</comment></comment></comment><comment><USER10> If you would want to generate some nice block diagrams displaying the components at different abstraction levels and the signals connecting them you could try synthesizing your design in Alteras' Quartus (a free version is provided on their website) and then using the Netlist / RTL viewers. It exports to PDF.</comment>


What is your best advice and web-articles when starting a new job? - <AUTHOR>

I am starting a job soon.
What is your best advice when starting a new job ?
What is the best web articles you have read about that ?
I would like to be effective from day one, but have always spent months to actually ship anything in previous jobs . It's a job as a web developer in a small web agency. <comment><USER2> From my own personal experiences, my best advice is to keep a positive attitude at work.</comment>


Facebook users unwittingly solve CATPCHAs, aid spread of Koobface - <AUTHOR> http://lastwatchdog.com/facebook-users-unwittingly-solve-catpchas-aid-spread/

<comment><USER2> Heh. So let's make sure I understand this. Solving the CAPTCHA will give the victim the illusion of regaining control of their computer, yet it's the last step in creating a Facebook account? I'm actually a little impressed by this one.

I'm not entirely sure I understand this part though: "The bad guys have made it difficult for Facebook to cut them off, since active members are actually creating the new accounts, says Correll." What difference would the creating account's age have when making a new one? Sure, it has the benefit of originating from a relatively legitimate IP, but the age of the now compromised account seems arbitrary in this context.

</comment><comment><USER3> "Attempts to play the video turns over control of the PC to the attacker"

How?

<comment><USER4> Clicking on the link led to instructions to download a Flash Player update required to view the video. Clicking on the video player update downloaded a copy of the worm.

</comment></comment><comment><USER5> And this is why captcha's aren't that effective. They don't slow organized malicious hackers who can simply hire a third world worker to solve them for $1/hour, make a botnet make its victims do it like here, and so on. Meanwhile, many people are actually having trouble solving them.

<comment><USER6> Agreed, although I'd quibble about the use of "that" (effective). They do set the bar fairly high and therefore stop a lot of "casual" vandalism and spamming, at the very real cost you note.</comment></comment>


Cambridge Analytica staff set up new firm - <AUTHOR> https://www.bbc.co.uk/news/technology-44807093 <comment><USER2> This can't be a surprise. A lot of firms in the professional services sector have no real assets, just the knowledge and relationships held by their staff. Bankruptcy doesn't transfer such things to creditors, and legal rulings stick with the old entity.

<comment><USER3> This is an example of leaks in the corporation="legal person" abstraction, the "intangible assets" abstraction.. or it's twin, IP. Some "stuff" is not like other "stuff".

</comment></comment><comment><USER4> Cambridge Analytica -> Auspex

Blackwater -> Xe Services

Operating in Africa, no less.

<comment><USER5> Xe Services -> Academi

</comment></comment><comment><USER6> I think their value comes from the collected data of Facebook profiles. If they just copy the data and their trained models, they essentially just use the IP that brought them into that mess in the first place.

All the knowledge doesn't help them, they'll need to use their models which they've developed at CA. Otherwise they can know a lot about machine learning and statistical methods, but don't have the data to train their models. I think it will be revealed that they just use the same data. Which is borderline illegal, IMO.

<comment><USER7> Their psychographic model was hugely overblown. A couple of Facebook likes do not mean they suddenly know the path to change your mind with some ads. They were just a political dirty tricks operative.

[https://www.theguardian.com/uk-news/2018/mar/19/cambridge- an...](https://www.theguardian.com/uk-news/2018/mar/19/cambridge-analytica- execs-boast-dirty-tricks-honey-traps-elections)

<comment><USER6> In the article you've linked, the whistleblower says: "the company itself was founded on using Facebook data" (watch at minute 09:00).

Their models might not be the most accurate, but they are a big part of their success. + all those dirty tricks they've pulled off.

</comment></comment></comment><comment><USER8> What did people think they were going to do just give up and go work on a construction site or maybe work at McDonald's

<comment><USER9> This is why people need to be punished, not just companies.

</comment></comment><comment><USER10> Another one? They already started emerdata.

<comment><USER11> > The company was set up by Ahmed Al-Khatib, a former director of Emerdata

</comment></comment><comment><USER12> If only LinkedIn allowed us to give these people negative endorsements ...

<comment><USER13> Nothing stops you from creating a quick website with details, screenshots, and good SEO to show up in Google.

<comment><USER12> Yeah, but Google allows one to issue a request for removal of a URL.

(Also, I'm not sure this would be the best way to deal with people like this, and I guess it would need more thought.)

<comment><USER13> If you own the URL. Others can only submit removal requests if the content no longer exists.</comment></comment></comment></comment>


Interactive checklist for your website - <AUTHOR> http://guestpostlabs.com/complete-checklist-for-your-all-your-website-needs/

<comment><USER2> Add this to the list

* Website does not break functionality of the 'Back' button

The list looks comprehensive, I'm not going to do the HN thing and claim you ruined the experience by, in this case, redirecting my click in such a way that I can't press 'back' to get back to the article discussion.

But there. I said it. More and more sites are doing this, I'm almost ready to remove the button from the UI of my browser.

I believe there is a way to perform this redirection without ruining the Back button. Anyone know how it should be done? (I'll hear compelling arguments on why it should never be done, too, or the opposition to that since it seems to be a popular trend.)</comment>


I gave out my online passwords - <AUTHOR> http://ywoodmanbrown.wordpress.com/2014/04/18/heartbleed-vs-proportionality/

<comment><USER2> I think I saw an interview with this guy posted before. I'll quote what somebody else said, because they worded it better than I would have: "I don't have anything to worry about, so none of you have anything to worry about either".</comment>


Is Model-View-Controller dead on the front end? - <AUTHOR> https://medium.freecodecamp.com/is-mvc-dead-for-the-frontend-35b4d1fe39ec?imm_mid=0ea80e&cmp=em-web-na-na-newsltr_20161109 <comment><USER2> MVC was originally designed as a pattern for desktop UIs. It has a _single_ controller and a _single_ model, not the MVC style that Rails popularized with one controller class and one model class for every kind of data. In classic MVC, Views query the Model for relevant data. The Controller handles user actions and uses that to update the Model, then asks the View to redraw (preferably in some smart efficient manner). This is unidirectional data flow _pur sang_ and it comes from 1988. How is React+Redux _any_ different from this?

I agree with the author that components are the true innovation of React, because it encourages reusable building blocks _by default_. Contrast with classic desktop and mobile UI toolkits which, while often also using or encouraging MVC, do not require the developer to not subdivide their own codebase into reusable widgets. Instead, they allow composing an entire screen (window, page, form, whatever) from the built-in widgets. Making a reusable widget is possible but extra work and therefore not done. In React, it's the only way to go.

This is awesome about React, but it has _nothing_ to do with data flow architecture, which is what MVC is.

The mistake webdevelopers made for years was trying to shoehorn DHH's backend remix of MVC into the frontend, throwing away decades of UI building architecture knowledge. I'm happy the Facebook people rediscovered MVC and I'm even happy they gave it a new name (Flux) because MVC frankly has gotten way too many definitions.

But saying that Flux/Redux killed MVC is like saying Clojure killed Lisp.

<comment><USER3> > MVC was originally designed as a pattern for desktop UIs. It has a single > controller and a single model

Not quite. Let me quote from "A cookbook for using the model-view controller user interface paradigm in Smalltalk-80" by Glenn E. Krasner and Stephen T. Pope, 1988, which according to Wikipedia defined the term MVC originally:

> In the scheme described above, views and controllers have exactly one model, > but a model can have one or several views and controllers associated with > it.

<comment><USER2> Good point!

All that said, they mean that you should use separate controller-view pairs for entirely different pieces of the application. A nice example would be MS Word's document editor (1 view with 1 controller) and MS Word's Print Preview view (same model, but a separate view and a separate controller).

What I was getting at is that in backend-MVC (and backbonejs-MVC), you usually build a view, a controller and a model for each domain entity (i.e. for each database table). This is fundamentally different from what Krasner and Pope describe, and it probably won't work well for the kinds of dynamism and interactivity most single-page apps are single-page apps for. I believe this is the flavor of MVC the author is talking about.

In our case at TalkJS, we don't have anything like a print preview - essentially our entire application is a pretty unified piece of UI (much like MS Word's document editor which, while complex, is pretty much inseparable), so we have only one controller and one root view. I made the thinking mistake that most UIs only have one root view, and of course that's not true. So thanks for that.

</comment></comment></comment><comment><USER4> Its the same pattern. The whole point of MVC isn't the damn precise implementation its about separating out the concerns of the view, the services/data and a thing or some things that control and/or glue it all together.

The point is to not munge all these things into one monolithic horrible grim mess. As long as you are separating the concerns of showing something to a user, allowing them to control it and backing it all with potentially remote service who cares what the pattern is precisely called? Its still flavours of this original desire that we named MVC.

All these presenter/unidirectional patterns are _just_ the underlying desire of MVC and the only reason that people seem to talk about how "MVC isn't right" or "is dead" is because they've followed MVC like dogma instead of just a guideline of separating your presentation, control and service logic. I had exactly this debate back when everyone was talking about MVP as if it was some revolutionary new thing. Its not, its all the same thing and GOF was never supposed to be a template for software but a way of talking about specific ideas that architects could then riff on. They're chords, not one specific tune that you _must_ play in a very specific way.

<comment><USER5> I agree completely. If you model is echoing long bits of HTML, or your views contain lots of SQL, that's not really MVC. Almost everything is just details. We get excited about labelling them as 'ADR' or 'MVVM' but they are all just variations on a theme.

Perhaps the problem is that rules like 'no SQL in your views' is now so ingrained, a lot of juniors have never seen a monolothic mess of SQL mixed with HTML. So MVC is almost ubiquitous, and we then try breaking it down into different sub-categories.

<comment> at-fates-hands >> SQL mixed with HTML

And now we have Javascript being mixed with HTML; which I never thought would happen.

<comment><USER6> JavaScript isn't a type of logic, it's a language. You wouldn't say JavaScript is the M in MVC, for example. If you have JS in HTML, and that JS code is strictly view logic, then your code still has a clear and useful separation of responsibilities.

</comment></comment></comment></comment><comment><USER7> > As more and more developers start to see the advantages of components and > unidirectional architectures, the focus will be on building better tools and > libraries that go down that path.

"Unidirectional architecture" is a weird name for what is a fairly standard abstraction. Every front-end at the top level is:

        f(my_entire_state, some_event) -> my_entire_state'

In the end all you need are well defined state transitions, an event bus and a main loop to connect the two. Persist the sequence of events for undo/redo, audit, debugging ... and the current state for caching or having durability between sessions. Push side-effects to the boundaries. You may find this is good enough.

Front-end development has been plagued by unclear patterns w/ weird names (MVC, MVVM, MXYZ...) since forever; everytime the patterns are criticized you hear "you did not understand it"; and new names keep popping up. It seems the industry is stuck remixing reasoning around nouns, and is unable to step back and reason around data.

BONUS: Sprinkle some CSP to get elegant concurrency, throw away callback-hell. Sprinkle some React to get fast DOM manipulation, throw away Flux (heresy!) - it has way too many names to worry about (action creator, action, dispatcher, callbacks, stores, store events, views) and encourages some bad practices around use of stores.

My $ 0.02

<comment><USER8> The CSP thing is something I've been looking at recently, and while it seems like it's a little bit lower-level than things like Rx, it seems like channels are more flexible streams (i.e. channels are two-way so you can do back- pressure etc.). I've been playing with [https://github.com/ubolonton/js- csp](https://github.com/ubolonton/js-csp) and it's pretty nice; the "yield" statements everywhere are a little wonky, but otherwise it seems like you can implement some pretty sophisticated concurrency between processes with pretty straight-forward code.

For examples of that sort of thing, David Nolen and James Long have written some really great articles on the subject:

[http://swannodette.github.io/2013/07/12/communicating- sequen...](http://swannodette.github.io/2013/07/12/communicating-sequential- processes)

[http://swannodette.github.io/2013/07/31/extracting- processes](http://swannodette.github.io/2013/07/31/extracting-processes)

[http://jlongster.com/Taming-the-Asynchronous-Beast-with- CSP-...](http://jlongster.com/Taming-the-Asynchronous-Beast-with-CSP-in- JavaScript)

There was also an article recently that described a flux-like architecture using channels that I found pretty interesting, but I can't track it down right now.

<comment><USER9> Those articles are excellent and held my interest since they were published, but at the same time React and Flux were exploding and I never saw any further talk of modeling UI logic with processes and channels. It is still in my notes: Take another look at Hoare CSP for UI programming perspective. I once asked David Nolen on twitter if he thought the CSP approach is still useful given the perspective of React/Om. He said yes but that was the extent of the conversation.

In particular, I have yet to see any examples of integrating the CSP approach with React or similar architectures. For example, can you hook a process-based autocomplete widget into a React view? Is anyone doing this or have we rejected CSP for UI logic? I am interested if you can find article you mentioned.

<comment><USER10> David has moved away from it, in OM.next you do not use CPS. You can of course, but it would only be a implementation detail and not fundamental to the structure of Om.next.

<comment><USER9> I think that's what I'm driving at: apart of the Om architecture itself, does it make sense to drop something like a CSP autocompleter into an Om app, or are those things incompatible?

</comment></comment></comment></comment></comment><comment><USER11> It's in times like this that I'm glad I don't blindly follow the hype. According to the consensus, I should have gone with Backbone.js in 2011 (then Knockout, Ember, Meteor, Angular…)

I'm still not completely convinced by React, and I may very well be wrong, but the same skepticism that sometimes makes me feel out of touch, also provides some sanity in this madness.

For some reason that I can't quite point out yet, Vue.js feels like the nicest one yet, though I've only played with it briefly.

<comment><USER12> If you went with Backbone.js (or similar) you would have been better off than the standard bag of jQuery methods. Curious what you ended up going with back then?

Most projects I start these days tend to use React. I've looked into Vue, and liked what I saw. I also maintain a 5 year old project built with Backbone.js (by someone else) and I'd say it checks all the boxes for maintainability, stability, and testability. It has its flaws -- as any old codebase will -- but I'm happy they went with Backbone. I'd probably be saying the same thing for the other frameworks mentioned.

Its easy to point out all the flaws from our past. Much more difficult to predict how thing will be in the future. Making a choice now, even the wrong one, is almost always better than clinging to things that are known to not work.

<comment><USER13> Exactly! So many people assume that the emerging of a new "best" way of writing front-end software renders all previous architectural decisions wrong.

It even came to the point that some people reject using any frameworks or even a helper like jQuery and "take everything under their control" because they don't want to deal with "deprecated" libraries.

Meanwhile, a small development team I know keeps using Knockout.js successfully in huge projects.

<comment><USER14> I'm a web dev since the beginning. Of all the frameworks I've worked with, Knockout has the most utility for the least obtrusiveness.

</comment></comment></comment></comment><comment><USER15> The whole "x is dead" is pretty common headline pattern. It's dramatic, extreme and often just an exaggeration.

I can guarantee that MVC is still used on the fronted as on the backend. People are still generating value from MVC apps.

Perhaps it's not held up as the holy grail, since the new holy grail is pronouncing it dead. Perhaps it is dying. Dead it is often not.

After building out some front-end MVC work, I can see the value in Flux architecture and React components. I'd have a hard time justifying a rewrite though. It's still very much alive there for me. That's also the case for many others.

</comment><comment><USER16> At the moment I'm sold on Mode-View-Intent, which is more delarative and non- OOP. I also have the feeling it lets me compose a bit more easy.

        DOMStream = view(model(intent(DOM)))
        DOMStream.subscribe(render)

intent() takes the DOM, wires up some interactions and returns streams "of" these interactions

model() takes streams of interactions, wires them up with data retrieval and mutation streams and returns these data-streams

view() takes the data-streams and uses them to create DOM mutations-stream, which it returns.

The nice thing is that these observable streams are really nice to filter, map, debounce etc. Also, it helps with fast realtime data stuff, because you can easily wire up these fast streams with a tiny part of your app and the rest of it won't even notice (which is a bit ugly if you got a big state-tree that represents your whole app state).

The not so nice thing is, that controlling them completely declaratively has a steep learning curve.

<comment><USER17> > model() takes streams of interactions, wires them up with data retrieval and > mutation streams and returns these data-streams

I think that's called a controller or presenter in other patterns.

Actually your view and intent also do what a controller would do. The DOM is your actual view, and your data your actual model.

<comment><USER16> You're right, the names are badly choosen.

In every function the same is happening, streams are created/wired up with other streams.

The differentiation here seems to be, that the Model function just wires up streams for the data, the View function just wires up streams for the display and the Intent function just wires up streams for the interactions.

</comment></comment></comment><comment><USER18> I closely follow the Elm way (but in javascript with React), and it's still pretty much MVC.

      Model = the state,
      Controller = the update function changing the state based on action.
      View = declarative, need to send actions to change the state. Gets redraw on state change.

Redux/flux are also similar.

The idea of MVC, as far as I'm concerned, is to separate the View (Declarative as much as possible), the State (Just data, no logic) and the Controller (Business logic receiving commands/actions/called/whatever which changes the states and let the view knows that it needs to update).

Is that pattern dead? Far from it.

<comment><USER19> But how do you update the view efficiently, and robustly (without introducing bugs or becoming less efficient as your view becomes more complicated)?

<comment><USER18> Well, this is exactly the goal of this pattern.

One thing I didn't mention is that I use MVC per component, not for the full application. (I use something else for the global Application level).

So, every major component has its own MVC. I.e. One page on mobile listing a items with a bunch of interaction would have its own MVC.

And why it's robust and efficient:

Very easy to reason about the data and write unit tests. The whole data is in the State, and only the controller can alter that state.

The view is completely decoupled because it can't change the state, it can only declaratively render something (we use React with immutable). And this is also very easy to test and mock with fake data.

As for performance, I've tried various strategies over the past few years, and I find Immutable data structure + virtual Dom pretty damn amazing. I personally use React.js + Immutable.js, mostly for the great documentation but this is definitely not the only libraries.

And if the view becomes that much more complex, then it's time to spawn a new component with its own MVC.

<comment><USER19> I don't think that works well if the view is a complex function of the state. You can break the MVC into smaller components with an inner state, but how do you know which components to update when the outer state is updated? I believe you can't know, unless you duplicate the complexity of the smaller components into your larger component.

<comment><USER20> From what I understand, react + redux has a couple of tricks up it's sleeve.

As the components don't hold state, only display the state of the model (part of the redux store state), components only need to be re-rendered if the state has changed.

If you combine this with reselect ([https://github.com/reactjs/reselect](https://github.com/reactjs/reselect)), then this allows you to only re-render components when the sub-set of the state tree is changed that can affect your component.

So to a certain extent you're registering your component's interest in a sub- set of the state, and then only re-rendering when that sub-section changes. The trick is then to ensure that as you build your app you don't build a single component that depends on everything and pass state down as props, but lots of smaller components that depend on a small sub-set of the tree.

<comment><USER19> Does that also work if the dependence on the state tree is not hierarchical? I.e., subcomponents referencing the state in a random-access way?

<comment><USER18> It would be much easier if you provided an example of what you have in mind. The approach I mentioned work perfectly for us, but it doesn't mean it'd work for you.

But to answer your question, it shouldn't matter if subcomponents reference the state in a random-access way. Our workflow is like this:

a) Main components fetch data from an external module. (That module either queries the server, gets the data from the client database or uses something already in the memory cache).

b) That main component generates a ModelView state. Basically, it transforms the fetched data into something it can use. It could mean joining models together, etc.

c) The view uses the ModelView state to render itself. Each component generates a virtual dom representation and then renders themselves in the DOM.

d) Now, there are two different ways this ModelView state can be altered:

      1) From a global event (eg. New changes came from the server. Or a component elsewhere in the app sent a global event.)

      2) From the component itself (eg. An event/action is sent from the view)

e) Either way, once that ModelView state has changed because of that event, the view gets re-generated very efficiently. I.e. Only the small part that visually change gets rendered.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> I have the feeling I am reading Vogue describing what should be the new trend this winter.

<comment><USER22> I have the feeling fashion entered the IT world in the era of the first tech bubble when being a geek suddendly became synonym for being rich, and open source technologies started to do marketing instead of white papers and specs. Not sure it's the best thing that happened to our field.

</comment></comment><comment><USER23> A component, a la React, is merely an opinion on MVC. M are props, and V is a pure function of these props. React encourages both M and V to live in the same file, which is a deviation from best practices in MVC land. But there is still an M and a V.

C, in the front-end world, has less of a direct equivalent, but can be thought of as your router, which React also has as a separate entity.

What MVC does not have an opinion on, is that the M is really one giant object, where each component receives a sub object of it. Where MVC can go wrong is when many objects have dependencies between their state. React comes along and says that two objects with a dependency should derive this shared state from something above them, not inside them. This is a useful pattern. It is still merely an opinion on how to organize Ms in an application. It is not something "different".

In functional programming, in its purest sense, there is no M. That's different.

</comment><comment><USER24> I'm a bit confused by the way the article describes MVC as going from "server- side" to "front-end" :)

When I was growing up coding native UI apps, MVC was all about front-end. UI toolkits were traditionally MVC or M(V+C) going all the way back to SmallTalk, and "server-side" typically meant apps without "V" or a "V" that was so small and hardcoded in without separation...

</comment><comment><USER25> Am I the only one thinking this kind of discussion is not hitting the nail on the head? I think the main issue with web UIs is the lack of good UI design tools, and nice and robust components. When I am developing a UI I am spending a lot of time writing code code while I just want to drag and drop components.

<comment><USER26> When has drag and drop ever worked for any programing environment?

<comment><USER25> VB6? Delphi? Windows Forms? WPF? Flash? QT? Xcode?

I am not saying I don't want to write a single line of code, just saying that the UI components can be assembled and "configured" with a design tool.

<comment><USER27> Having started on Android and then gotten into a Delphi environment, Android development tools seem like they're directly evolved from Delphi.

</comment></comment></comment></comment><comment><USER28> We've sort of evolved in our stack, which leans heavily on two less-popular options (MobX + Horizon), towards a pattern that I now think of as invaluable.

I started calling it Model-View-Store recently as I think that best describes it. There are a few unique things here that I think are valuable.

Starting with Models: Models all return observable values. So if I query for a single record I get back an observable object, or a list, observable array. I define `@query` decorators on the models to set up these queries. Model's include prop validation, normalization, consistent operation names, and more.

Views come in two types: application and presentational. App views are all decorated to automatically react to mobx observables, so you can literally have a Model `Car` and in a view call your query `Car.latest()`, and your view will trigger the query and react to it accordingly. One line model <-> view connections!

Then you have Stores: they are just logical containers for views. Any time a view needs to do more than some very simple logic for a view, you can attach a mobx store to it with very little code. Stores also can manage the data from the Model (and because the Model returns observables, this is usually a one- liner). But they don't have to. Stores are located side-by-side with the views they control (and are be passed down to sub views when needed).

I've been working on this system for a bit now along with our startup and we've been able to deliver some pretty incredible stuff very quickly. Having a consistent model system is crucial, I can't imagine programming without having prop validation and a single place to look for my model queries.

Going to be releasing pieces of it over coming weeks and hopefully a full stack example thats really legit soon.

</comment><comment><USER29> I worked with MVC before, but eventually I found that DDD (Domain Driven Design) is what I'm looking for. Domain Driven Design is more like a set of rules of how to apply the existing design partners (eg: repository, factory and aggregation) and building blocks (eg: layering architecture) to design your business models and keep the integrity, invariance between data. Moreover, it lets you easily define the boundary between your services for Microservice architecture.

MartinFowler DDD blogs: [http://martinfowler.com/tags/domain%20driven%20design.html](http://martinfowler.com/tags/domain%20driven%20design.html) Book: [https://www.amazon.com/Domain-Driven-Design-Tackling- Complex...](https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity- Software/dp/0321125215)

</comment><comment><USER30> Isn't this akin to what has been called MVVM in WPF land, or Presentation Model pattern by Martin Fowler, both more than a decade ago?

You have Model, View, ViewModel, and whatever auxiliary libs those need.

<comment><USER31> From a comment to the article:

"The unidirectional data flow approach that's in the spotlight right now thanks to Facebook is actually pretty darn close to what "real" MVC (as in the design pattern introduced first in Smalltalk decades ago and not the "server- side" appropriation that frameworks like Ruby on Rails popularized) is."

<comment><USER32> Exactly. If you ignore misappropriation of terminology like the server-side "MVC" frameworks that had very little to do with MVC, and you ignore modern buzzwords like "unidirectional data flow" for the old idea that interactions update the model and that leads to updated rendering, then front-end web development today is following a broadly similar path to what general GUI architectures and visualisation tools did about 10-20 years ago.

People have noticed that views and controllers tend to come in pairs, and experimented with how to set up the controllers to receive events without creating excessive coupling.

People have noticed that you often want some sort of intermediate state derived from your model to support your view rendering, instead of regenerating expensive data from the model itself each time you render.

People have noticed that rerendering everything can be a bottleneck and developed tools for identifying only the changed areas to render selectively.

Tune in next week for: Immutable data structures are relatively slow. Large- scale declarative rendering is relatively slow, even if you use diffs. Fine- grained publish/subscribe models are relatively fast, and flexible enough to cope with both computing derived state and triggering UI updates, but you need good tools and a clean design or the edge cases will overwhelm you. Small- scale declarative UI updates triggered by a fine-grained publish/subscribe model is a useful approach in a lot of cases. And everyone hates temporary/transient state in forms.

<comment><USER33> We went the reverse: fine-grained to coarse-grained. The "aha" is that the speed is just not a big enough deal for most cases. Consequently, go full declarative for the 95%, and only go fine-grained for the 5%. More concretely: we went from mostly Rx to mostly React. Both have their strengths, but it's not a 50/50 thing in terms of lines of code.

<comment><USER32> In my experience, it depends very much on what you're doing.

If a UI has light to moderate rendering requirements, React's approach might be fast enough on its own. In that case, a lot of the other ideas are just extra complexity for no real benefit. I'm speculating here, but I'd guess this actually accounts for a large majority of the web front-end work that is being done today.

I haven't found that React alone scales very well to more demanding environments, though. If your model has significant constraints between the data points that need to be enforced or you need non-trivial view-state between your model and your rendering code, you're back to having dependencies in the data that need to be implemented somehow. That is outside React's scope, so something else needs to bridge the gap.

I find React's design itself also struggles with scaling up beyond a certain point, though it's a high bar that I expect most UIs running in browsers wouldn't reach. However, if you're implementing something like a complicated dashboard with many data dependencies and interactions, you start needing shouldComponentUpdate almost everywhere to achieve acceptable speed. That has profound implications for how other parts of your app are structured because you need some way to make shouldComponentUpdate fast, and it can also lead to more and sometimes artificial subdivisions of your rendering components so you can use shouldComponentUpdate at the necessary level of granularity.

Overcoming those scalability issues usually seems to bring me back to the approach I mentioned before for larger, more complicated UIs: data dependencies are handled through some sort of observer model and/or lazy queries, but a library like React is still useful for declarative rendering of each smaller part of the UI so you don't have to worry about transitions most of the time.

<comment><USER33> FWIW, it's worth considering we (graphistry) work at the edge of what is possible in browsers. We hook up GPUs in the client to GPUs in the cloud for an unprecedently rich visual analytics experience. Think building Netflix, Photoshop, or Google maps for data. If mostly react and falcor, with only sprinkling finegrained rx, is how we handled the perf and composition mess, I'm pretty sure simpler apps can do even less than us.

<comment><USER32> Looks interesting... You're doing statistical visualisations using WebGL and GPU acceleration? If that's right, would you mind sharing a little of how you're setting up your overall architecture?

The web projects I'm working on are in a slightly different field. We also seem to be pushing the practical limits of browser-hosted GUIs with some of our interactive visualisations, but they tend to use SVG. WebGL is one of the technologies that is definitely on my "could be interesting/useful" radar, but I haven't tried to do anything serious with it yet, so I'm wondering how different a real-world-scale project would be.

</comment></comment></comment></comment></comment></comment></comment><comment><USER34> For anyone interested in a surprisingly pleasant to use front-end MVC framework I am a huge fan of [http://mithril.js.org/](http://mithril.js.org/).

It espouses a (I believe?) slightly more traditional MVC interpretation where your Controllers are usually extremely light and in most cases completely optional. It encourages a MVVMC (Model View View-Model Controller) approach to encapsulate view-state.

</comment><comment><USER35> I think there is a problem defining MVC. If you argue that current innovations in the frontend do not violate MVC, then MVC is a very useless term. If you think of an very conservative, OOP definition of MVC i don't think React fits the model. Of course that means that many other frameworks are not truly MVC, but MVC-inspired, but i don't have a problem with that.

</comment><comment><USER36> Great article, couldn't explain the pain better. I worked a lot with Angular1 in the past couple years, and the controllers tend to get very messy because a lot of ui state and app data mixed together in the controllers. I am using React for most of my apps now, but I look forward to see what frontend architecture will come out in the next few years. I feel as ES6/7 is getting more and more common for js development, probably some OOP patterns that are used in Java/C# will be developed for frontend, but of course, front end apps is still different from Java server apps because of the nature of the language and the purpose of the app (frontend is more view and user interaction oriented)

</comment><comment><USER37> Agreed. MVC has always been sort of an awkward pattern for frontend web development. The fact that the DOM is extrinsic to the JS runtime can lead to a messy collaboration of MVC components. An input that makes an AJAX request on each keystroke and renders the results to a list (typeahead.js for example) is easy to implement but involves quite a bit of indirection with this paradigm.

That being said, I don't know how to feel about Angular 2's approach to components. Decorators are useful but can diminish the benefits of component based architecture when misused.

</comment><comment><USER38> > The Controller is highly dependent on the View.

OP is painting with an overly broad brush: Angular is not representative of all client-side MVC. I maintain an app where the view handles the browser events - as it should, and the only data that gets passed between the view and the controllers are the (business) models.

</comment><comment><USER39> On android, MVC is dead. Talk about overly-circuitous code that is not straight forward to step through. MVP is great, when not over-done by folks as well (eg making a model-view-presenter unit recursively for every element on screen rather than having one unit associated with the a given screen).

</comment><comment><USER40> So what if anything COULD replace components and unidirectional architectures in five/ten years?

</comment><comment><USER41> I wouldn't say MVC is dead in the front-end, rather I would say MVC is a necessary stepping stone towards modern front-end architecture. It still has some kind of model, view and whatever the controller is called.

Before the time of Single page applications, MVC was not practical as the state of the page would be destroyed as soon as you click on a link. With the whole "single" page approach your page lives on and your applications remains. This was the considered the "holy grail". We are thought all the problems are solved, but then came the performance and memory leak issues. Because the page lives on throughout the user journey, memory management became a problem.. and so was SEO. As always front-end will continue to change rapidly year after year and it's now all about Flux/Redux and Universal javascript?

Saying MVC is dead is like saying "CPU" is dead, no it's not, but it will always keep on improving.

</comment><comment><USER42> Well, we still use Models and Views, but not with React or Rails, no no no. With _classic ASP_. Also I'm not sure as to where the line is being drawn between frontend and backend...

</comment><comment><USER43> MVC never made sense on the frontend, unless it was a completely silo'ed frontend app with no backend.

</comment><comment><USER44> i write ember code and for me it still lives a lot, though MVVM

</comment><comment><USER45> MV __arises naturally. You can run the entire application logic without UI components, and you can test it that way also.

Other abstractions are designed similarly to allow tests against pieces of the internal API in total isolation, though separated on different lines. Maybe you have transient state stored in view models while persisted state is stored in models. The isolation only helps as size grows, and it can keep size under control mostly by having a good data model for what each component / layer / aspect actually does.

It makes it easier to rewire everything when you start with a switchboard. UI changes are either "Oh my god we're going to have to re-write so much stuff if we do it that way!" and you wind up not making drastic UI changes or "Sure, we can make that thing tickle the controller instead of that other thing."

</comment><comment><USER46> Yes, and good riddance.</comment>


First Solar's new world record for solar cell efficiency and why it's important - <AUTHOR> http://gigaom.com/2013/02/26/first-solars-new-world-record-for-solar-cell-efficiency-and-why-its-important/ <comment><USER2> Let's not forget that the most important number in solar cell technology is, not maximum cell efficiency, but watts per dollar expended on installed capacity (i.e. W/$). Measured that way, competing technologies shake out differently, and the most efficient cells aren't necessarily in the running.

But for the future, as the most promising technologies gain an advantage because of volume production, the relationship changes and the most efficient cells may become contenders in the more fundamental W/$ competition.</comment>


Find everywhere you can go in 15 minutes or less - <AUTHOR> http://flowingdata.com/2011/06/01/find-everywhere-you-can-go-in-15-minutes-or-less/ <comment><USER2> This is an awesome idea. I would love to find an apartment this way. Finding an intersection of places you can meet a friend is a perfect extension to the concept. I hope they take off and support more cities!

<comment><USER3> I'd like to find an apartment this way too, but I'm skeptical as to how well they handle bicycling in concert with San Francisco's crazy hills.

At least having the topo map would be nice. :S

(P.S. other than that, AWESOME).</comment></comment>


I just installed Visual Studio 2010, now how do I get Code Contracts? - <AUTHOR> http://blogs.msdn.com/bclteam/archive/2010/01/26/i-just-installed-visual-studio-2010-now-how-do-i-get-code-contracts-melitta-andersen.aspx

<comment><USER2> Maybe it's just me but I thought that meant "I just installed Visual Studio 2010, now how do I make money?"

<comment><USER3> Interesting. The capitalization on "Code Contracts" (as opposed to "code contracts") suggests to me that it's a proper noun, and your interpretation didn't occur to me until I read the comments. Since you've been upvoted many times, a lot of people seem to agree with you.

Is English your native language? This seems to be the sort of thing that non- native speakers might miss, but I don't really know.

</comment></comment><comment><USER4> Code Contracts seem rather silly. C#/VB is statically typed, no? Method contracts should be implicit in the method declaration, then.

Granted, this gives you more control over what literal values may be passed to a method. But isn't that (part of) what exceptions are for? What additional value do these add?

<comment><USER3> It looks like a fairly powerful static analysis framework, well beyond what the C# type system can prove. Not sure what exactly it can do, but the static checker dialog box allows you to enable:

      Implicit Non-Null Obligations
      Implicit Arithmetic Obligations
      Implicit Array Bounds Obligations
      Redundant Assumptions

If it can do a good job of checking these statically, I'm impressed!

</comment></comment><comment><USER5> I hope it is at least as good as Spec# <http://research.microsoft.com/en- us/projects/specsharp/>

<comment><USER6> Or at least comparable to what the Cobra language has for contract support: <http://cobra-language.com/docs/quality/></comment></comment>


Show HN: REDasm Disassembler 2.0 - <AUTHOR> https://redasm.io/ <comment><USER2> Nice! A lot of open source debug tools don't have terribly great UIs and this one looks pretty good. I can't imagine it's as versatile or intelligent as IDA, but on the other hand for the low price of FOSS it is hard to be disappointed. Especially since my hopes of affording a copy of IDA for my hobbyist reverse engineering is basically nil.

This is definitely going in my toolchain of RE apps, alongside x64dbg.

<comment><USER3> You shouldn't feel bad about buying an (expensive) license if reverse engineering a hobby of yours. Computing is such a cheap hobby it's OK to splurge every once in a while. And there's a good chance the skills you build end up paying dividends later.

Compare computing to other hobbies. Anything involving cars/boats/motorcycles: expensive. Woodworking, metalworking or anything else that requires a shop: way expensive. It's easy to spend thousands upon thousands on most hobbies every year. In contrast with computing you can do almost anything with very basic tools.

It's great when there are high quality free tools out there. But most of the time these free products get abandoned or are left unfinished. It's hard to get a community of volunteers to do the schleppy maintenance work for 20 years when the product is already feature-complete. And that's why we should be glad there are commercial alternatives, even if they're a bit pricey.

<comment><USER2> It's actually a lot simpler than that: I can't afford it. I don't have the free cash at the moment. I am focused on eliminating debt and increasing savings and I can't do either if I spend some grand on an IDA Pro license.

<comment><USER4> Maybe you really can't afford it, but given the job opportunities this is a bit like saying that you can't afford college. The cost with all 5 decompilers is about $15,000. That is comparable in cost to a semester of college. It might be a better deal if you bother to really learn the tool.

I guess there aren't student loans for IDA, but there definitely is employment. Once you become competent with IDA, you can apply for jobs like these at my workplace: [https://news.ycombinator.com/item?id=19284153](https://news.ycombinator.com/item?id=19284153) Being competent means you can navigate around in a binary without symbols, that you can mentally convert assembly to C, and generally that you can find things of interest in the binary and understand them.

Binary Ninja (binja) is $149 from Vector35. That might be optimal for you.

<comment><USER2> I feel you may misunderstand me. I _do_ have a nice comfy job at a big company, in the Bay Area, as a software engineer. My career is still young, so I don't have a ton of savings. I couldn't afford college; I went to a cheaper one, took about a year's worth of classes before my debt became too much higher than my income and gave up. That's a big part of the equation, along with a car loan I still owe a fair bit on. Luckily I found most employers did not care about the lack of a degree and so began my career without much trouble.

I realize someone's probably going to comment that I'm an idiot for living in the Bay Area, but consider this: after living expenses, I still make a fair bit more than I did in Detroit, and I much prefer living here. So it is what it is.

I think in a few years I should be more than capable of buying an IDA Pro license, but as it stands I am not taking on that debt for a hobby. As for whether or not I will get a job doing reverse engineering, I think it's unlikely any time soon, though certainly possible in the future.

That's a lot more context than I feel is necessary to explain why I can't casually drop $3k-5k on a hobby, but hopefully it makes more sense.

</comment></comment></comment></comment></comment><comment><USER5> Does anyone know why this disassembler might be a good choice over another open source option like Medusa or Radare?

I'm very interested in this stuff. I tried getting into IDA before I had a good understanding of programming and it was a struggle. I have been thinking about trying my hand at it again lately.

<comment><USER6> Radare is also pretty difficult to learn on.

</comment></comment><comment><USER7> This looks very nice! But posting it a day ahead of NSA's Ghidra unveiling? It's going to be buried in the noise :(

<comment><AUTHOR> I know about Ghidra, the release day is just a coincidence.

There is no problem btw, I have posted here to see if someone was interested to the project. In any case I will continue to develop REDasm because I use it at work and I need it.

</comment></comment><comment><USER8> I get "Graph creation failed". I tried to achieve the same thing that can be found on redasm.io. Any ideas why or how to fix? Tried with 2.0 and nightly.

<comment><AUTHOR> Open an issue on GitHub: [https://github.com/REDasmOrg/REDasm/issues](https://github.com/REDasmOrg/REDasm/issues)

<comment><USER8> Hold on, I see that it needs D3/Dagre/Dagre-D3. I am installing a few packages from AUR. It may work in a bit!

<comment><AUTHOR> Everything is bundled in the executable!

When you see that message, for some reason REDasm cannot generate a path for the current function and it should be fixed.

<comment><USER8> Ah. I do not have a GitHub account right now so I cannot create an issue. :(

</comment></comment></comment></comment></comment><comment><USER9> That looks great! Any plan to run on macOS?

<comment><AUTHOR> I don't own a Mac, so I can't test the generated binaries.

Someone reported me on Twitter that it compiles fine on a 64-bit OS with Clang.

It doesn't compile with Clang on a 32-bit OS (there is a bug report for that).

<comment><USER9> So, I'm on macOS, 64bit, trying to compile with clang, and I get some errors concerning comparisons between size_t and u64 values. I was able to progress a bit by changing some size_t to u64, or the opposite, but I'm quite sure that I'm breaking a bunch of things at the same time :)

I will continue a bit then open an issue with details.

<comment><AUTHOR> It looks like this: [https://github.com/REDasmOrg/REDasm/issues/14](https://github.com/REDasmOrg/REDasm/issues/14)

But the OP doesn't answer so I can't fix it

<comment><USER10> Please publish a binary/dmg. This would be sweet. Thank you for getting this to work on macOS :)

<comment><AUTHOR> It's WIP: I'm receiving bug reports and pull requests for macOS support

</comment></comment></comment></comment></comment></comment><comment><USER11> If one is on Debian, here is a partial list of QT packages one might want to install to try this out:

        qt5-default
        libqt5webengine5
        libqt5webenginewidgets5

Also it needs at least QT5.9, but Debian Stretch only has QT5.7.

</comment><comment><USER12> Downloading now. I realize it's not IDA, but does anyone have any preliminary comments on how practical, fast and useful this is for disassembling x86-64 binaries?

<comment><AUTHOR> Hi, I'm the developer. And I'm also a fan of IDA-like environment.

REDasm is a project that tries to mimic IDAs interface and shortcuts but with a nicer, modern API.

About the quality of x86-64 binaries: it should be pretty good (but far from perfect).

Obviously with more binaries and test cases the quality of the generated listing can be improved!

<comment><USER12> I like the interface. When I saw "RED" I thought it was developed in Red's system language.

The release of Ghidra by the NSA has stole some of my attention. Given your expertise, what are your thoughts on Ghidra aside from the source? Thanks!

<comment><AUTHOR> Well, it's a personal opinion (and I haven't used Ghidra too much) so:

The UI is a lot 90s/ish and a bit unconfortable to use, but it ships a great decompiler and it can render nice graphs, the quality of the generated listing is good, but inferior compared to IDA's one.

And...Java...

</comment></comment></comment></comment><comment><USER10> Sweet! Good to have an IDA alternative!

I hope the pricing remains sane once you guys make it big :)

</comment><comment><USER13> Any keyboard shortcuts? Can't seem to find any docs on it

</comment><comment><USER14> So I use capstone regularly. This sounds like a ui layer on top?

<comment><AUTHOR> Capstone is just a backend above LibREDasm: you can create a new architecture from scratch.</comment></comment>


Wired.co.uk 'Design of the Year' is UK government's data website - <AUTHOR> http://www.wired.co.uk/news/archive/2013-04/17/design-of-the-year

<comment><USER2> Title is misleading. Award was handed out by London's Design Museum, not by Wired.co.uk.

<comment><USER3> I find it quite ironic that the Design Museum website is horrifically ugly.</comment></comment>


Ask HN: In your career, what are you most embarrassed about? - <AUTHOR>

In your career, what are you most embarrassed about?<p>Have you made a fatal mistake that you, of all people, should never have? <comment><USER2> Getting used to a salary off the bat. My first job offer out of college was >250K, and I stopped living frugally too early.

</comment><comment><USER3> Staying too long in a comfortable job and not leaving solely on my own terms.

</comment><comment><USER4> I majored in Latin, thinking that teaching jobs would be easy to come by when, in fact, they weren't. That cost me around 6 years, with the dubious benefit that I was fluent in a dead language and that I nearly know the etymology of a fantastic number of words in English.

</comment><comment><USER5> Not starting soon enough - but then again would have missed out on a helluva ride. Embraced, enjoyed, and lived each phase to the fullest. Feel a little behind now but if I didn't then I'd probably procrastinate, so it's a nice fire-under-my-ass. :) All in all despite not getting straight there, no regrets because the journey itself has been great!

</comment><comment><USER6> I find the best entrepreneurs aren't embarrassed by much of anything and seem to embrace their mistakes.

</comment><comment><USER7> Not firing someone incompetent I'd hired (as a favor) as soon as it became obviously necessary, who later went on to embezzle a lot of money.

</comment><comment><USER8> Not sticking up for myself.

Don't wait for some theoretical FU money.

The people who have FU money, if they didn't inherit it, seem to have incorporated my first point into their lives. (Not that money is necessarily the outcome.) Also, sticking up for yourself does not equal being an ass to other people. For myself, treating other people nicely/respectfully is inherent to my own well being. And I actually do worse at it when I am _not_ taking care of myself.

As for the "I should never have made the mistake" aspect. My intellect, and/or my intuition, could read the situation. But lack of will power, conditioning, health, or whatever -- something held me in place.

</comment><comment><USER9> I didn't get the PMP cert after it cost me the offer from google.</comment>


'Mind Over Matter': Stephen Hawking – Obituary by Roger Penrose - <AUTHOR> https://www.theguardian.com/science/2018/mar/14/stephen-hawking-obituary <comment><USER2> I really like this obituary, this is exactly what I was looking for.

Penrose not only understands the details of Hawking's work at a much deeper level than most of us, but as a contemporary of Hawking's he has followed his career for decades and can give us a good overall impression.

</comment><comment><USER3> The author of the obituary, Roger Penrose, is also a distinguished and forward thinking scientist. I highly recommend reading his book "The Emperor's New Mind". It's especially relevant in today's climate of rapidly accelerating machine learning and A.I. advances (whether you agree with his premises or not).

<comment><USER4> Just for the record, almost nobody accepts the thesis of that book. Penrose is a great fundamental physicist who believes (or did back in 1990) that new fundamental physics is needed to explain how brains produce intelligent behaviour.

The dominant contrary opinion is that this can be done using some form of computation. Other opinions are that something other than computation in the Turing sense is required, but that current physics is probably sufficient to describe it. Very few people think that a theory of e.g. quantum gravity is the right level of explanation for the phenomena of intelligent behaviour.

I think Penrose fell into a common trap: when you are an expert on hammers, every hard problem looks like it needs a whack with a better hammer.

<comment><USER5> I don't think Penrose's position is that you need new physics for intelligent behavior, but rather that new physics is needed to explain consciousness. There's a big metaphysical difference between the two.

<comment><USER4> I guess that's true. Then it's even more bold and wacky to declare that we need new physics to describe a thing that is so controversial in its function or effects.

I (possibly mis-)translated into intelligent behaviour in my memory, since that's something most people agree does real work and needs explaining.

</comment></comment></comment></comment><comment><USER6> This isn't an ordinary obituary - it actually describes Hawking's contributions to physics from the perspective of another renowned physicist. Really well written.

</comment><comment><USER7> An accessible summary of the part of Hawking's work that we can digest at present, by someone in a position to know. Don't miss the last paragraph.

</comment><comment><USER8> I wonder if caloric restriction may have strengthened his immune system and increased his life expectancy?

EDIT: I thought I should do a quick search on that idea and it turns out that I am not the first person to have asked that question: [http://forum.lowcarber.org/showthread.php?t=463854](http://forum.lowcarber.org/showthread.php?t=463854)

</comment><comment><USER9> Can also recommend Penrose's Cycles of Time: An Extraordinary New View of the Universe, for an interesting take on his own view of cyclic cosmology.

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

</comment><comment><USER10> A fitting tribute, from a man who fully understood both the man and his work.

Roger Penrose's book "The road to reality" is great if you want a high level overview (and list of topics) for mathematical physics (The scary stuff!).

</comment><comment><USER11> _Hawking is survived by his children._

</comment><comment><USER12> WARNING: AMP link

Non-AMP link: [https://www.theguardian.com/science/2018/mar/14/stephen- hawk...](https://www.theguardian.com/science/2018/mar/14/stephen-hawking- obituary)

<comment><AUTHOR> If this is considered a problem, could one of the mods please change the link to this desktop site url?

<comment><USER13> Why would it be considered a problem? The amp page linked there is clean, loads fast.

<comment><USER14> AMP-usage is pretty contested in these regions, and using an AMP link can be seen as a political statement in favour using AMP. I would avoid it if possible.

<comment><USER14> Also, if you're like me and you use Firefox & block 3rd party resources by default, the AMP page will show a blank screen for about 5 seconds, whereas the conventional link will load the text instantly.

<comment><USER15> Or as I do, use reading mode in Firefox.</comment></comment></comment></comment></comment></comment>


Spaceship Earth - <AUTHOR> https://en.wikipedia.org/wiki/Spaceship_Earth <comment><USER2> Hm, yes, I've always like that term. Maybe it's time to re-popularize it. The issues it points at are more relevant than ever, and it's really, really urgent now that more than anything else we understand that we are all, after all, in the same boat.

</comment><comment><USER3> And how do we move our spaceship?

I was amazed to know that theoretically we can move our solar system.

[https://www.youtube.com/watch?v=v3y8AIEX_dU](https://www.youtube.com/watch?v=v3y8AIEX_dU)

</comment><comment><USER4> I always thought the phrase was from Buckminster Fuller. Interesting to see the idea originated with Henry George.</comment>


Ask HN: What math background do I need to understand FP languages? - non-entity Languages (and users of languages) like Haskell, OCaml, Adga, Idris, etc. seem to be at least somewhat based on a lot of CS and mathematical concepts. The way people talk about and evangelize these languages makes it seem like that backing theory is necessarily to use and understand the languages.
What all CS and math subjects should do you need to know to take full advantages of FP languages like this? What background do you need to approach those subjects? <comment><AUTHOR> I'd say go to the source and read John Backus's original paper[0] on functional programming. Yes, there's some math in it so you could read up on that but the narrative text itself is enough to convey the important concepts of FP.

[0] [https://dl.acm.org/doi/10.1145/359576.359579](https://dl.acm.org/doi/10.1145/359576.359579)</comment>


Show HN: Sell Your Anonymous Health Data to Research - <AUTHOR> https://www.nukleosome.com/ <comment><AUTHOR> The project is also open source; [https://github.com/nukleosome](https://github.com/nukleosome) with strong focus on encryption/security, in case anyone is interested in contributing

</comment><comment><USER2> Interesting. How do I know what kind of research my data will be used for?

<comment><AUTHOR> You'd be asked for a consent that includes the research description & details.</comment></comment>


Gradio – GUIs for Faster ML Prototyping and Sharing - <AUTHOR> http://gradio.app <comment><AUTHOR> Link to github: [https://github.com/gradio- app/gradio](https://github.com/gradio-app/gradio)</comment>


Ask HN: Is there an API that allows me to extract the text from an article? - <AUTHOR>

 I wonder if there is any API that allows do the same as Instapaper or readibility. In particular you can select any web page and just get the text, removing the navigation menus and advertising. I'm on a project that needs to analyze several Internet news sites and extract the contents. The problem is that each Internet portal has a different structure that is difficult to add a new site.<p>Greetings. <comment><USER2> Viewtext [1] provides an API that gives you clean(er) HTML. It still contains some markup but is vastly simplified. You can also roll your own with tools like HtmlCleaner [2] or lxml [3]

[1] <http://viewtext.org/>

[2] <http://htmlcleaner.sourceforge.net/>

[3] <http://lxml.de/>

<comment><AUTHOR> Thanks I'm going to check out. I google about text extractor software and I found AlchemyAPI

</comment></comment><comment><USER3> <http://www.diffbot.com/docs/api/article></comment>


Show HN: Password generator (terminal) - <AUTHOR> https://github.com/knuthy/genpiepie

<comment><USER2> > import Crypto.Random.random as rand

Kudos for using an appropriate random number generator.

<comment><AUTHOR> Thanks, PyCrypto is an outstanding lib.</comment></comment>


Avow-CI Is No More - <AUTHOR> https://github.com/Fluidbyte/avow-ci/ <comment><USER2> As is often the case, the problem here could have been avoided if there had been clearer and more open communication.

All this guy had to do was go to his employer and say, "Listen, you should know that I'm working on an open-source project that is in the same ballpark as what I'm doing at work. However, there is no shared code, a different architecture, and the two don't even compete against one another. Plus, what I'm doing is open source."

If his employer had said, "Yeah, go ahead -- no problem," then there wouldn't have been a problem.

If his employer had said, "We're all in favor of open-source contributions and projects, but not when they compete against our core products, from which we make money," then they could have worked out a deal. Or not. But at least it wouldn't have been left up in the air like this.

I definitely see a problem with an employee creating an open-source project in the same space as his commercial, day job. While a cease-and-desist order is pretty unpleasant, all they're saying is that he has to stop work on the project. It could have been much worse, and much more expensive.

It also seems weird to me that while the former employee is saying he needs to stop, he's letting others fork the code and keep going with it. If I were interested in picking up an open-source project, I'd be hesitant to join one in which there had been explicit legal threats against the original author.

<comment><USER3> There are a couple of interesting things in what the former employee says

1) He claims the commit logs are proof of when he did the work. They aren't, they are simply proof of when he did the commits.

2) He says, "I worked on it in the evenings after I had completed my work for the day." Which instantly makes me wonder whether he was doing this on a work computer after hours?

If you want to do open-source work on an area related to your job you must talk to your employer first, and whatever open source work you do you should be sure you're either not using company resources or have permission to use them. Commit logs cannot prove when you did the work, they can only prove you did them at or before that point.

<comment><USER4> >If you want to do open-source work on an area related to your job you must talk to your employer first

I promise you that's not the law.

A bartender that makes drinks for his friends at a house party doesn't have to reimburse his employer for skills learned when tending a bar.

> and whatever open source work you do you should be sure you're either not > using company resources or have permission to use them

But this is a valid point. If you're using company hardware and resources, you're arguably spending resources owned by the company.

<comment><USER5> I would argue that this is a moot point since computer hardware is a commodity. Most companies around here buy their employees new hardware and said employees will simply use them for all their computing needs as is convenient (would you travel with 2 laptops just to be able to claim you didn't use company hardware).

I frankly find this kind of legal posturing by companies abhorrent and immoral. It's almost like treating employees as slaves.

<comment><USER4> >I would argue that this is a moot point since computer hardware is a commodity.

The cost of the hardware is recognized (in accounting) over the life of the machine.

>(would you travel with 2 laptops just to be able to claim you didn't use company hardware).

I have a really nice computer from work and an old laptop at home. I use my old laptop for all personal projects to avoid just such an issue.

</comment></comment></comment></comment></comment><comment><USER6> The company is AppendTo.

"In appendTo, we've constructed our business model to encourage our staff to keep an effective and balanced schedule. The definition of work-life balance is unique for each person, but we've built our organization with the features and tools that empowers our employees to customize their interaction with appendTo to their needs. This manifests itself many ways, from flex time to giving our engineers time to work on personal growth or open source projects."

\-- [http://appendto.com/company/values/](http://appendto.com/company/values/)

<comment><USER7> Shame on them. They used to be a front runner in web development tutorials and it seems they have built a company out of that.

A quick pro-tip for appendTo: if your company's business model is in building things for developers, don't do scummy things to your developer employees.

<comment><USER8> Shame on them for not wanting an employee to take what they've learned at work (on a monetised product) and release it open source? The tech stack is largely irrelevant, the products are in the exact same domain.

I think any company would be rightly pissed off if their employees did that. Can you imagine github, for example, being happy for one of their employees to be working on a complete web front-end / issues tracking system for git, in their spare time and releasing it open source, provided it was written in Java? Or Atlassian being happy for one of their employees writing a complete ticketing system in their spare time, and releasing it open source provided it was written in javascript?

Really?

<comment><USER9> That is completely within the employee's rights. Unless it's covered by a trade secret, patent or copyright, what you know (even if you learned it on the job) is yours to use.

<comment><USER10> How would the employee know what is a trade secret though? When something is first discovered it is not known yet that the employer would want it kept secret until someone in a position to make that decision does so.

Are their laws around this? Or is it set mostly through case law? Anyone have additional information?

<comment><USER11> IANAL, but the important pieces (in most states) come from the Uniform Trade Secrets Act[0], which defines a Trade Secret. I'm pretty sure that most software ideas developed at software companies can be considered trade secrets, unless they're commonly known, but once again IANAL and don't have a solid handle on that.

[0] [https://en.wikipedia.org/wiki/Uniform_Trade_Secrets_Act](https://en.wikipedia.org/wiki/Uniform_Trade_Secrets_Act)

</comment></comment></comment></comment></comment></comment><comment><USER12> This is a sad story, but it could have been seen coming from a mile away:

\- He worked on a personal project during company time. Edit: Oops. I misread this one as the inverse of what the author was saying. He only worked on it _while employed._ Still very ugly given the field of his work.

\- His personal project is directly related to his work.

\- His personal project conceivably competes with his employer's products.

\- The company does not have staff in NY or CA, so the author lacks even the minimal limitations on non-competes imposed by state law ([http://newappendto.wpengine.com/wp- content/uploads/2013/12/1...](http://newappendto.wpengine.com/wp- content/uploads/2013/12/100-Remote.png))

All of these things are typically barred by completely reasonable non- competes. As the author, I would absolutely expect to receive a C&D. As his former employer, I would feel (personally) hurt, even betrayed, by this behavior.

<comment><USER13> Either you don't quite understand the purpose of a non-compete or there's an entire class of them I'm not aware of (which is entirely possible), but in my experience, their purpose is to explicitly bar employees from poaching customers from the business.

Working on something in your personal time that's similar to what you're working on for your employer -- unless your employment contract is entirely unreasonable -- isn't and shouldn't be a violation unless you are using company resources (including but not limited to trade secrets learned in the context of your employment and not legally available through other sources).

<comment><USER14> Non-compete is a somewhat generalized term being used here, but it can mean what you referenced ("don't poach customers") as well as "don't steal our product ideas". These are sometimes called NDA or PIIA (1) which might be better representations of what we are talking about here. In this case, the company is claiming that he stole their code (an 'invention' or 'property' of the company) for the benefit of some other party.

NDA or PIIA agreements are common in software development.

1 - [http://en.wikipedia.org/wiki/Non- disclosure_agreement](http://en.wikipedia.org/wiki/Non-disclosure_agreement)

</comment></comment></comment><comment><USER15> It's one thing to work on unrelated open source software while working somewhere. It's a much more tenuous situation when you're working on OSS in the same domain as your commercial software, even if the entire technology stack is completely different. Unfortunately it sounds like the employer's claim might have some legs in this case.

<comment><USER16> I would disagree.

What you do in your personal time is none of your employers business he is not paying for that time and he does not own whatever you create in that time.

Not unless you signed a ridiculous contract saying something like that which in my opinion should not be enforceable anyway.

It's like a construction company saying it owns the house you built for your family just because you happen to work for them and you gained experience by working for them.

They certainly didn't supply the raw material which in programming would be time and effort so they shouldn't have any claim on it.

<comment><USER17> I disagree. Your employer is sponsoring a lot of your learnings in a specific area, so he's entitled to all your ideas in that area, that's what your paid for. It would be extremely easy to just keep your best ideas for "your" project and not use them in your work project.

The construction company would have a valid claim if you stole the blueprints at work.

<comment><USER18> > Your employer is sponsoring a lot of your learnings in a specific area, so > he's entitled to all your ideas in that area

No, he is not on either count.

> that's what your paid for.

I don't know you, but I'm paid for the work I produce, I'd be really happy if I could be paid for learning stuff and not doing shit.

> The construction company would have a valid claim if you stole the > blueprints at work.

Yes. It would not have a valid claim if you built stuff on the side, even if it's better stuff. Your company does not own your knowledge, which is why non- compete agreements are invalid in just about all jurisdictions unless _very heavily_ compensated (in Germany it's _at least 50% of gross_ and no more than 2 years, and clauses can still be found unreasonable and invalidated).

<comment><USER19> In the US, most white-collar jobs have contractual clauses that grant the employer rights to IP produced by the employee, even after work hours, if such IP relates to the work the employee performs for the employer.

These clauses are enforceable in every state, though some states such as California limit the breadth of "related" to the specific industry or industries in which the employer operates.

</comment></comment></comment></comment></comment><comment><USER4> This isn't what I have in mind when I think "open-source bullying." This is standard corporate lawyer sending of C&D orders.

<comment><USER7> Agreed. This should be renamed to "Employer bullying open source now-former- employee." It's an incredibly crappy situation and the former employee is doing exactly what the Employer wants, not defending themselves due to the expense of doing so.

<comment><USER20> _It 's an incredibly crappy situation and the former employee is doing exactly what the Employer wants, not defending themselves due to the expense of doing so._

... and protecting (rather than naming) the employer, something the employer also wants, out of fear of causing a reputation issue for "bad-mouthing" an ex-- in this case, an objectively _deserving_ ex.

We need representation, agents and collective bargaining, like actors and writers in Hollywood. This event just proves that, because we (as tech workers) fail to fight for our own, employers can get away with far too much shit.

</comment></comment></comment><comment><USER21> This seems less like bullying and more like a company enforcing a 'do not compete' clause in the programmer's contract.

Even if its a different stack, they would have had access to things like A/B testing, client feedback and client names if he wanted to try selling his version!

<comment><USER22> I don't know how you can create a better mousetrap if you can't use your knowledge of the industry gained on the field to build it.

<comment><USER23> So quit your job at MouseTrap Enterprises before you go off and build your better mouse trap. If you have a job as a MouseTrap inventor at MouseTrap Enterprises and you have a great idea for a mouse trap, it does seem kind of sketchy to go off and create your better mouse trap at home on the weekends while you're cashing your MTE checks. That is what they're paying you for..

</comment></comment></comment><comment><USER24> If he is based in California then the court systems will put the onus on they company for proving his project infringed. There are three things I've learned to remember in California about moonlighting; Don't work on any project that has the same goals as one of your employers project, get clearance in writing when you start, and keep good notes.

Early in my career doing hardware design on my own was 'easy' since I was always employed as a software engineer, and number two (get clearance) really helped me understand both how cool NetApp was and how bogus Google was in what they consider 'their space'. Number three helped early on, keeping a notebook I found was helpful for me to keep from _not_ bringing things from work home into my projects.

</comment><comment><USER25> Open-source bullying is when someone says "your code sucks and you should kill yourself!".

This is more of a company enforcing that you do not copy the systems they are doing to minimize competition. Many times when people leave they try to create same product that previous company created.

</comment><comment><USER26> Welcome to my world :)

14\. Intellectual Property and Related Rights

14.1 All records, documents, papers, databases (including copies and summaries thereof) and other original matter, work or creation (collectively "Creations") made or acquired by the Employee in the course of the Employment shall, together with all copyright, database rights and design rights both registerable and unregisterable that subsist in all such Creations worldwide, be and at all times remain the absolute property of the Company.

14.2 The Employee hereby irrevocably and unconditionally waives all rights granted by Chapter IV of Part I of the Copyright, Designs and Patents Act 1988 that vest in the Employee (whether before, on or after the date hereof) in connection with the authorship of any copyright works in the course of the Employment with the Company, wherever in the world enforceable, including without limitation the right to be identified as the author of any such works and the right not to have any such works subjected to derogatory treatment.

I wonder if I can teach my 2yo daughter alphabet or counting 1-2-3 or would she become property of the company?

<comment><USER27> I think the key here is how "in the course of the Employment" should be interpreted. Is it anything that happens during the dates you are employed, or is there a requirement of some connection to the employment?

</comment></comment><comment><USER28> Another reason to work for an employer as a consultant, so that you control your own IP and time.

I'll keep saying this until one day talented programmers get the message. If you're creating open source frameworks, you're talented enough to not have to take any bullshit from employers. Offer them your services, and nothing else.

Sadly, the state of health insurance in the US makes this somewhat difficult.

</comment><comment><USER29> I get that this can be generic, and we can discuss this as a open source issue with an employer asserting their rights, but I want to take a more direct approach to the specific situation.

Does a company really think they are able to achieve and sustain a competitive advantage from controlling a continuous integration system? What is the business rationale here?

<comment><USER30> If they do a lot of consulting, they could have heavy third party approval processes or some other consulting workflow structure in the CI that "greatly" improves their customer experience or engagement in the dev process.

I am not sure that there would be a burden on the employer to even prove value though.

</comment></comment><comment><USER31> Shouldn't the title of this submission be that on the page, "Avow-CI Is No More?" The submission title was previously highly editorialized, now changed to "Open-source bullying or just the company's right?" but I think that's still pretty slanted and limits the discussion to only two viewpoints.

<comment><USER32> Yes, the title was against the rules and we changed it. I didn't see the previous one, but if it was worse it must have been really bad.

All: Please don't editorialize titles, especially not to make them more linkbaity.

</comment></comment><comment><USER33> If it was legally released under an open source license, someone can and should grab it before he deletes it, put it somewhere else, and people other than him can certainly legally keep using it or working on it, right?

I guess the employer could try cease-and-desisting others and claiming it is their IP and the open source license was not legal.

<comment><USER34> Yes. At least in my country. That's why I forked the repo and perhaps see if it is useful maybe I'll even commit something.

I think they will have a hard time tracking down me and then fight a legal battle overseas. If they were to send me a C&D letter I would simply not comply, answer or do anything. First they have to find my address though.

A lot of people already has forked it, the code is available in a ta, maybe even in the history. Because of the seemingly bad communication now it will never go down.

</comment></comment><comment><USER35> Not sure it won't get deleted along with the original repos that I forked it from, but at least here is the repos reverted to the last useful commit:

[https://github.com/lucb1e/avow-ci/](https://github.com/lucb1e/avow-ci/)

And if it gets deleted, I have the code locally.

</comment><comment><USER36> This whole situation is really sad. I don't know if he violated any terms of his contract or not (and I take him at his word that he didn't reuse code), but I certainly understand his position that his family and livelihood are more important than fighting some lawsuit.

That said, I think this highlights and important point -- when you work on outside projects that are even tangentially related to your full-time job (and by that, I mean, if you are an engineer, any software you write, not just stuff associated with what you write at work), it's important to get that cleared and approved in your contract. Preferably at the time of hiring.

I'm a writer and reporter. I can't make money or even contribute articles for free to a publication that could be considered a competitor -- that's obviously clear. But when I was hired, I was working on a few freelance projects that were not directly related to my main employer. I got it in writing that those projects (including things like podcasts or magazine work) are clear. Every year when I review my contract, I make sure those points remain intact, along with the new names of other projects I work on.

But if I were to start another creative project, even one that on the surface didn't intersect or compete with my employer, and I didn't get that cleared (or I didn't already have the ability t do so in my contract), that would absolutely be a problem.

</comment><comment><USER37> Shouldn't we name names in this case? This behaviour should be part of the company's public image. Or does that just greatly increase the legal risk for the author?

<comment><USER38> I personally would not do business with or purchase products from a company that decided to threaten an ex-employee in this way. But then, I am not an important person.

</comment></comment><comment><USER39> Could have been worse

[http://en.wikipedia.org/wiki/Sergey_Aleynikov](http://en.wikipedia.org/wiki/Sergey_Aleynikov)

</comment><comment><USER40> A lot of good comments here, and I think the OP stepped in it a little bit. It should have been a wee bit more obvious that the overlap was likely to cause some concern, so chalk this one up to a professional learning experience, which as others have pointed out could have been a lot more costly.

Another factor, imo, is that regardless of how supportive of open source your employer is, human jealousy and possessiveness still comes into play. Nobody is getting as much work done as they would like, and they never will. When a manager hears about an open source project I guarantee you some little corner of his or her brain feels like they want those hours for themselves. I've seen this emotion inadvertently aired on more than one occasion. If the project in question is truly a side project and truly unrelated then the manager's best course is obviously a held tongue. But it if is potentially competitive? Now the reaction has legitimacy, and for that reason alone it's best to steer well clear of anything that might be a conflict.

</comment><comment><USER41> Depends on your employee agreement, and where you live. Most of the companies I've worked at said that anything related to any of their business was theirs, regardless of the times that I worked on it. Since a large company does a _lot_ of things, you're pretty much down to selling fruit or watercolor paintings of stuffed animals, if that. (I believe that Microsoft has a blanket "No moonlighting" that they want to apply to _all_ jobs; makes those paying hobbies interesting).

My current employer doesn't care at all, and gives explicit permission in the employee contract. I can even write stuff that is in their business space, as long as I do it on my own time and equipment. Very enlightened.

</comment><comment><USER42> His former employer is claiming that he worked on it on their time and that he stole code. He denies these claims and even offers some evidence to prove it.

So HN says he should have discussed it with them, he probably had a non- compete clause, he probably conferred his intellectual property to his employer in his contract, or that his actions are just in general bad form.

BULL - The companies claims are pretty specific and if they are false as he claims then their behaviour is indefensible.

I'm shocked that the HN community is in favour of this.

</comment><comment><USER43> Doesn't it just come down to what's in his contract? Many contracts now do include a clause assigning copyright to all employee code (even that written outside work) to the company. I would never sign such a contract, but it's a perfectly reasonable thing to put in one.

In the absence of such an explicit clause I am pretty sure that copyright automatically belongs to the author of the code.

</comment><comment><USER44> I would have preferred it if he had included "what was practically a cease and desist letter". It would be easier to judge the case if you knew what his employer was asking him to do in their own words.

I have worked in the game industry for a long time and it used to be said that code walks with programmers. The use of open source repositories may end up making this more visible.

</comment><comment><USER45> Another 'big guy bully small guy' story, there seems to be a lot of these nowadays. Again, the law doesn't protect the small guys at all does it. Shame Really.

appendTo on the blacklist of companies to work for, someone should make a site with a collection of companies with these kinds of behaviour, so people are aware. last one I read about was Goldman Sachs.

</comment><comment><USER46> It's sad, but a rule of thumb is: "never EVER open source anything that is close to your employer", because people don't care how different your open source project is. They see what they monetize on, so they sue. Unless you really do something generic, like "yet another social network for kitten owners having foot fetish" ;-)

</comment><comment><USER47> ah..am I missing something?..source is still up in release download section

<comment><USER7> The README states that the entire repo will be deleted on April 18th.

<comment><USER48> Presumably, lots of people will fork it before that time.

<comment><USER7> I wasn't going to out right say that :) I don't want the repo owner to be held accountable for that.

<comment><USER49> He isn't accountable, he is complying with the C&D. His company can go ahead and try if they think they can censor the entire Internet of his work.

Information freedom is a wonderful thing.

</comment></comment></comment></comment></comment><comment><USER50> This is why I don't have kids. So I can irresponsibly and irrationally fight the good fight. Sorry for your loss.

</comment><comment><USER34> I forked the repo, but I think I will actually see if I can put it up in a non-forked repo so it'll be a tiny bit harder to take down. Also I am starting a private repo as backup on another git service.

They will never be able to shut it down now lol. I think the communication of the employer was really bad even if it's not that good to do the same at home as you are doing at work.

</comment><comment><USER51> That's why the easiest way to improve the world by open source is to only commit anonymously.

sad, but true.

</comment><comment><USER52> Wow, the repository is really gutted out.

In the case I needed to do something like this, how would I?

</comment><comment><USER53> Is this a case to use a personal corporation and submit open source code?

To limit liability...</comment>