Hacker Newsnew | past | comments | ask | show | jobs | submit | eLobato's commentslogin

It also means incredibly slow context switching


Wouldn't it make context switching faster because you don't have to invalidate any TLB entries?


Context switching is more efficient due to less context.


I no longer make that kind of money through any side project but I did during ~ a year of college. It was one of the worst projects (coding wise) I made, and I made it all through ads.

It was just an Android soundboard app for a very popular TV show in Spain. You could tap a button and it'd play some funny sentence from a character from this show. Long press, you could share that sound.

Revenue model: a little ad bar on the bottom of the screen.

It grew from 60$/month to > 1000$ in around 6 months, only through word of mouth. That lasted another 6 months or so until the show became less trendy.

Probably not very sustainable as I was piggybacking on the popularity of the show, but it taught me that making money was 100% not about writing 'the bestest codes'.


IANAL, nor am I in Spain, so I don't really know what I'm talking about. My sense, though, is that in the US the TV show owners could sue me for copyright infringement, and I'd be on the hook for up to $150,000 in damages for each "infringing work" – I'd think that means audio clip, in this case.

There's a "fair use" defense to that (where I'd say that the clips didn't impact the market for buying the original work) and they might not go after me anyway, since it would presumably reinforce the popularity of the show.

Was any of that stuff you ran into? Or is there no similar copyright concern in Spain?


There was an eventual copyright complaint and cease&desist which I had no intent to fight. I talked with a lawyer (friend of my family) who said I could probably win or find a settlement in court.

They only went after the app a few years after the show was in its prime (it was making ~40$ a month more or less) so I just removed the application from the Android Play Store as that was all they were asking for.


Foreman does discovery [1] (PXE, PXE-less, segmented networks, through bootdisk) and handles BMC, I wrote the API in fact :)

http://theforeman.org/plugins/foreman_discovery/4.1/index.ht...

Maybe you were not aware because it's a plugin, we kind of have that problem in the Foreman community, plugins are not as visible as they should and they can contain key features.


Foreman is working on Puppet 4 support [1], and I'd say we'll try to push it forward sooner than later as soon as we complete the migration to Rails 4. Foreman is the upstream for Satellite 6.

[1] http://projects.theforeman.org/issues/8447


Red Hatter here. We have open sourced all acquisitions, I don't know what exactly leads you to think it won't be open sourced, the FAQ just states there'll be a timeline, as it was the case previously for ManageIQ (manageiq.org)


Actually this is a godsend for me. I've been meaning to experiment with Rust, and I keep a ~/NOTES directory with these kind of notes. Hopefully I'll contribute something soon!


The Thoughtworks radar [1] has done a pretty good job in the past of predicting which technologies would catch on and which ones wouldn't.

http://www.thoughtworks.com/radar/


> It's frustrating. People are "big upping" each other because they look like each other. People are big upping each other because they are white. And if I big up somebody because they're black it's a problem somehow. [...] We have a similar skin tone, and in fact, I do want to support somebody who looks like me. I think that's a good thing. Let's encourage that. I don't see why that is frowned upon. I don't see why that's reverse racism.

I'm really sorry but if you're 'big upping' anyone in any job because their skin tone matches yours, it is a big problem no matter the RGB of that tone. I'd be embarrassed every morning when I see my face in the mirror if I treated/hired some of my peers better just because they 'look like me'.

Great article overall, but I cannot say I agree with this 'we take care of our people, you take care of your people' attitude. Whether in a minority (hint: I am) or in a privileged position, I believe you should treat everyone equally, reflect on how you've been doing so and try hard to overcome your biases. I'd love to hear other people's comments on this.


This is quite cool, and actually something I'll propose to use at some http://github.com/theforeman repos.

I didn't really understood the format rules, so if the author posted this, a help section would help. I try to enforce

    '%(type) #xxxx(: | -) %{description}'
How would you do that? #xxxx is just an issue number, so it can be #23891, and after that I want a separator from the description, semi colon or hyphen are fine. Probably %{scope} can be used but I didn't really understand it from the inline help, sorry!


Hi, thanks for the feedback, it would be great to be used by a project like Foreman!

Currently the string for the format only allows the 3 defined variables, type, scope and description. I have been using this style at https://github.com/Gazler/changex/commits/master to give you an idea of how it works.

I was concerned that the format string might be a little weird to get from the help. I will try and clear this up a bit.

I have attempted to build the string that you requested, currently an or separator is not supported, but I can take a look at adding it in.

Here are the format strings that I think match your use case. Using a colon as a separator:

    test string: "Fixes #1234: foo"
    format:      "%{type} #%{scope}: %{description}"
    [type: "Fixes", scope: "1234", description: "foo"]
Using a hyphen as a separator:

    test string: "Fixes #1234 - foo"
    format:      "%{type} #%{scope} - %{description}"
    [type: "Fixes", scope: "1234", description: "foo"]
I hope this makes sense, let me know if you get it working!


Interesting, that makes sense. I'll check if the rest of the team would be ok with forcing commits to use colon as a separator until that feature is added. :)

Still, what does %{scope} actually catch? Anything that's not %{type}, %{description} or an explicit character?


Glad it made sense!

So the match is exact between the non %{..} characters. The idea for scope is the context of the commit, in my libraries I use the name of the class as the scope.

For example with the default format string:

    test string: "fix(User): ensure email address is required"
    format:      "%{type}(%{scope}): %{description}"
    [type: "fix", scope: "User", description: "ensure email address is required"]
So any literal characters are matched exactly and anything inside the capturing %{...} is assigned to that variable.

This does fall over in the following case:

    "fix():(User): ensure email address is required"
    "%{type}(%{scope}): %{description}"
    [type: "fix", scope: "):(User", description: "ensure email address is required"]
It is certainly a candidate for improvement in the future.


Foreman could use some help - http://theforeman.org/ , contributions can be made to https://github.com/theforeman/theforeman.org

In particular, use cases that demonstrate its value proposition are lacking, API docs miss examples, and the manual has some outdated parts. The layout of the site is a bit dated too, but "it worked for us".


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: