What I Learned From My Startup Failing - <AUTHOR> http://snapsummit.com/conference-news/7-things-i-learned-from-my-startup-failing/

<comment><USER2> You're giving up after less than a year? I have a rule of thumb. I think that If you want to start a startup, make sure you're willing to devote at least 3 years to getting it going. Otherwise, don't bother. It's difficult enough to get a business off the ground at all, without trying to do so with an extremely tight time constraint. A corollary to this rule I suppose is that you should ensure that you have 3 years worth of resources and motivation before deciding to take a gamble on a startup.

I know it's easier and quicker to create a web startup today, but remember that you are still ultimately interfacing with the rest of the world. The rest of the world still moves at a rather leisurely pace. A lot of successful companies really don't start taking off until the third year of business. The rule of thumb is that for the first year, you're usually losing money. By the second year, you're hoping to break even, and by the third, should the business prove to be viable, you start making a profit. Even in the case of technology companies where this does not hold true nearly as much, there should at least be a parallel resemblance to this trajectory. Instead of being profitable in year 3, perhaps a technology startup begins to generate revenue, or is cash flow positive. The key characteristic is that in year 3, some sort of inflection point for success is reached.

If you don't hit this inflection point in year 3, you probably will never hit it. It's safe to say that you gave it your all, and quit the endeavour. If you do hit that inflection point in year 3 though, the proverbial sky is the limit. But in my opinion, it really does take 3 years worth of effort to say that you really put in a concerted effort.

Do you have the resources and will to give it some more effort? My advice to you is not to consider your current startup a failure. Rather, visualize your startup as a swimmer that's trying to cross a lake but has underestimated the direction and flow of the current. So you're a bit off course from where you need to be. The answer is not to give up on where you wanted to go, but instead change your tactics and find another route to your destination. Maybe it's longer, takes a bit more effort, and requires more time.

All the problems I see with Trogger are ones whose solutions are within your ability to solve. To me, Trogger appears to be a Web 2.0 version of Usenet. Except that it does not address any of the the problems that plagued Usenet:

 _The inability to prevent spammers from ruining the dialogue._

 _The fact that conversations in Usenet needed to stay on topic so that finding conversations was easy, but in real life conversations seldom do and people enjoy it that way. Reward tangents. People go off on tangents in conversations because they want to remain engaged. They leave conversations when they're unengaged. Why would you want people to leave your conversations?_

 _The short history of the web has shown that protocols don't make much money by themselves. You don't want to be the protocol of conversations on the Internet. Instead, choose a niche and be the conversation for that niche. Look at Stack Overflow as an example. If the Stack Overflow website was simply released as a general discussion platform, I'm pretty sure the thing would have tanked._

If I were in your shoes and I had the resources to survive for a little while longer, here would be my abstract thought process:

1) Reduce the scope of the problem. You know what discussion boards traditionally suck? Healthy living/workout ones. They're all sh*t, but there's a lot of money in that market. Find a market like that and be THE forum for that market, like Stack Overflow is for software devs looking for technical answers.

2) With the scope reduced, take the opportunity to refactor the user experience. Do you still need to integrate with Twitter and Facebook? If not, cut out those features. Cut out everything you possibly can until you've distilled the design down to the useful minimum. Then don't add features until you start seeing your users really hacking the system to their needs, like posting ascii diagrams to try to illustrate a point (e.g., if you did not have an ability to post pictures).

3) The most important part... Everything you do needs to be thought of as costing money or making money. Ideally your strategy involves trying to balance a cost with a revenue generator. For example, simply to host the site will cost you money. Instead of waiting for $1M to fall out of some VC's hands into your lap, start thinking about ways to offset this cost. On the easy end of the spectrum is ad revenue. Implement ads in a way that people are used to and that will begin to make you some money. Then try to grow this revenue. On the other end of the spectrum is trying to find sponsors. This task will be easier if you have narrowed your scope in step 1 and are targeting a specific market. For example, if you decide to become the ultimate discussion place for plastic surgery, Google plastic surgery and find out who's buying up ad words. Find a way to get in contact with them and offer them the ability to sponsor your website for a fee.

Now, whenever you go to implement a feature you can ask yourself the question "Will this feature make my users happy and cause them to use the website more, thus making sponsors happy or make me more ad revenue?" If not, don't implement the feature. If it will just make them happy but won't make them use your website more, don't bother doing it. It's amazing what this distinction can have in making a business a successful one or not.

<comment><USER3> re: walking after a year:

this is curious to me. on the one hand, success can spring from numerous failures, the numerous implying fast! imagine the inventor always inventing, multiple projects at once! a new one every week!

on the other hand, success can spring from committment and dedication. stay focused, don't give up.

i'm not refuting your points--in the end, one has to be smart, strategic. go all out in the right way.

<comment><USER4> You're an airplane pilot trying to get your bird off the ground. You have to attain a certain velocity to succeed. If your runway is short, you'd better open the throttle wide -- and if it isn't working, you have to decide pretty quickly to give up and try again.

But if the runway is longer, you have more time: continue building speed until you have enough force to lift off.

You just want to avoid giving up when you had plenty of runway.

<comment><USER2> Much more succinctly put than I could have put it, but spot on! The problem I'm seeing is a greater number of pilots that think they're flying Harrier jump jets when they're really piloting Cessnas :)

</comment></comment></comment></comment><comment><USER5> _"Companies succeed with single founders all the time. Just look at Digg, Craigslist, eBay, Netflix, Wordpress, Wikipedia, Amazon, TechMeme, PBWiki, TechCrunch, TechMeme, and Etsy."_

Is this true? I know it's hard to define "founder" precisely, since some co- founders may get involved after the idea is partly baked, or may not have as much of an impact. But several of these seem to be questionable. (And Techmeme is misspelled... twice.)

<http://en.wikipedia.org/wiki/Wordpress> \- "It was first released in May 2003 by its co-founders Matt Mullenweg and Mike Little as a (considered the official) successor to b2\cafelog." (Or if you meant Wordpress.com / Automattic, it also has multiple co-founders.)

<http://etsy.com/about> \- "Etsy was founded by Rob Kalin, Chris Maguire, Haim Schoppik and Jared Tarbell in June, 2005."

<http://en.wikipedia.org/wiki/Netflix> \- "Netflix was founded in 1997 in Scotts Valley, California by Marc Randolph and Reed Hastings, who previously had worked together at Pure Software, along with Mitch Lowe."

<http://en.wikipedia.org/wiki/Digg> \- "Digg started out as an experiment in November 2004 by Kevin Rose, Owen Byrne, Ron Gorodetzky, and Jay Adelson."

<http://en.wikipedia.org/wiki/PBworks> \- "PBworks (formerly PBwiki) is a commercial collaboration service created by David Weekly, with Ramit Sethi and Nathan Schmidt joining shortly thereafter as co-founders."

<http://en.wikipedia.org/wiki/Wikipedia> \- "Launched in 2001 by Jimmy Wales and Larry Sanger..."

<comment><AUTHOR> You're right -- "founder" is a tough measurement. A lot of times -- as in the case of my own company, RFOP -- one person starts a company, sees a bit of success, then quickly brings on a small group of peers who join with the "co- founder" moniker.

As a company grows, it quickly evolves from a solo effort to (some variation of) a team effort. This can mean bringing on employees, or people who join as "co-founder." At PayPal, for instance, more than a half-dozen of the first employees were accorded "co-founder" status, which is why the company appears to have so many.

Further complicating the matter, many companies change their story after they reach success, presenting a company as a joint effort or team project, rife with co-founders and collaborators, when the truth is closer to one visionary bringing an idea to life, and assembling a team thereafter.

For instance, Digg. I was at a dinner a few years ago and had the pleasure of sitting next to Owen Byrne, one of the people mentioned above. Owen wrote the original code for Digg. He told me that Kevin Rose found him off of ELance. Until then, he was a fairly unknown Canadian programmer. His success has surely increased since taking on what started as a $2,000 contract gig, but I hesitate to call him a "co-founder."

99 times out of 100, companies build teams in order reach success. However, in many of those circumstances, that kernel of success starts not with a small team reaching consensus, but a single visionary with a single vision.

<comment><USER6> Obviously I'm biased, but Kevin had little if any vision other than finding a new job. And he was much less known then he is now, after a careful, well- crafted and expensive PR campaign. And yes, I was an "unknown coder" but also an MBA, Ph.D candidate, and I spent years haranguing the business editor of our local paper about how corrupt the news business was. Many people I respect have summed up Kevin in a single word - "shallow."

And to reiterate, elance was not involved in digg. That also was part of the PR campaign.

<comment><USER7> I remember getting one of those email postings from elance a year or two ago, where it was explicitly mentioned about Digg being started through elance. What is the real story then?

<comment><USER6> That's impressive. I did do a couple of small jobs for Kevin nearly a year and a half before digg, so I guess they can claim we were introduced through it. But there were so many new fees and restrictions on providers that it was just a nightmare to use by the time digg appeared, that I had moved on.

</comment></comment></comment></comment></comment><comment><USER8> _When you're met with confusion, doubt, and dismissal, it's time to reevaluate. The world, collectively, is smarter than you are — pay attention to it._

I learned exactly the opposite from my startup. I was met with blank stare after blank stare as I explained my idea over and over.

As it turns out, if you are going after a non-mainstream market as I was (Internet culture), you're going to get this reaction a lot.

Okay, so my startup isn't huge. But it pays for itself and my modest salary. It's been 3 years now!

<comment><USER9> This works across the niche spectrum from "Internet forum trolling simulation game" to "bingo card creation software". _Customers_ validate ideas -- the opinion of non-customers is irrelevant.

</comment></comment><comment><USER10> _4) Talk to people and listen to them closely The world, collectively, is smarter than you are — pay attention to it._

I feel like a lot of great companies would never have been built if the founders didn't ignore a bunch of naysayers. That said, if you get your product into users' hands early and often and nothing you do can persuade anybody to like it, you're probably better off not wasting any more time on it.

 _5) The fewer heads, the better_

I'm going to have to agree with pg and say that going it alone is a bad idea. You need multiple, complementary skill sets. You need to balance out mood swings. You need varied backgrounds and bodies of experience to provide multiple perspectives on all the problems you'll undoubtedly face.

However, I can totally relate to the author when he says, "On many occasions, I'd come up with a new, inspiring idea, only to get a knot in my stomach before pitching it to my team."

I think it's important to cultivate a culture where it's perfectly acceptable to throw crazy ideas on the table and get them shot down. In fact, I think the more ideas you can burn through, the better. Creativity is an iterative process. Often times your crazy, will-never-work idea will spark a brilliant idea in the mind of one of your cofounders.

On a related note, we've found that getting a 3 person consensus on everything is a broken model. For any given decision there should be exactly one person responsible for making it. You can either divide up the problem space or you can just defer to the same person on everything. We even decided to rotate who gets to wear that hat every 4 months, to give everyone a chance and to make sure we don't stagnate.

<comment><AUTHOR> 4) Yes, you're right. Naysayers do abound. I refer to the world's "collective" opinion because, yes, it's all too easy to find a token naysayer who's eager to shoot you down.

That said, once you have a beta out, or some kind of working concept, the world becomes your sounding board -- where else, after all, will you get your users and customers? While it's important at some point to ignore what people think, it's just as important to keep at least half an ear open to their thoughts and opinions. I believe that you can learn more by listening deeply and attentively to people than by ignoring them.

5) As I said in the post, teams work for a number of people. They're one of the most common structures for getting companies off the ground. In the case of companies with strong technical needs, they can be particularly helpful, as different people can bring different skill sets and perspectives that may prove to be instrumental.

That said, I challenge the widely-held assumption that a founding team is necessary, vital, or inherently "better" than starting a company by yourself, and bringing people on later.

I hold that a single person, charged with focus and determination, can launch a concept with speed and single-mindedness that's difficult to replicate in a team environment. A team, despite the benefits it confers, adds added complexity to decision-making, and can dilute an idea as easily as it can rally behind it.

<comment><USER11> You can only bring on people later if you are successful, but becoming successful on your own is so damn hard and psyche destroying, if you don't see some success in a reasonable amount of time, you won't get there alone.

Do your next startup alone and come back and tell me if having two other bright and motivated people standing next to you is a bad thing.

</comment></comment></comment><comment><USER12> Again repetition in short published list. <http://news.ycombinator.com/item?id=834697>

"Companies succeed with single founders all the time. Just look at Digg, Craigslist, eBay, Netflix, Wordpress, Wikipedia, Amazon, TechMeme, PBWiki, TechCrunch, TechMeme, and Etsy."

</comment><comment><USER13> 1) Pick a problem and solve it.

Interesting, Christian never mentioned any of the "problems" Trogger wanted to solve. It does seem, at first glance, that this idea was a solution looking for a problem.

<comment><AUTHOR> You're absolutely right. This was one of our biggest failing points from the time we started. We built a cool, graceful, elegant solution... that ultimately solved little.

</comment></comment><comment><USER14> i'm not sure what to make of my situation. i've been working at my small business for a full 3 years now. i think the internet can make for a really different start to companies now. i had great attention and great sales at the beginning. then a huge lull because i changed the aesthetic and didn't realize how much that would impact my sales. so i changed it back and again sales were good. the the recession hit. and sales have been terrible. i'm still getting items up for this season and will see how that goes. but the area of the market i occupied is not good for anyone right now.

so how do i assess all this? is this a keep going and wait it out thing? am i failing or is it just the market.

i am now finally hurting for cash. i kep my overhead low through all this and was strategic about material costs too. but now that isn't helping.

</comment><comment><USER15> I would really like to see a Tufte style graph showing: a) number of people involved over time, b) % of time spent by each person, and c) profitability for the same time period, with a wide range of failed and successful startups.

Assuming one could come up with a way to clearly display that information.

</comment><comment><USER16> This FailCon advertised on the blog looks like a terrible idea. Why are the Meebo founders speaking? Meebo isn't profitable. There are only like two people from profitable companies there.

</comment><comment><USER6> "Companies succeed with single founders all the time. Just look at Digg..." Bad example.

</comment><comment><USER17> OK let me tell you something.

You have no idea why your startup failed. It has relatively little to do with the things you listed.

Your startup failed because you named it "trogger".

The name of a product, technology, website, whatever is critical for success. The name "trogger" makes me think of "troglodyte" or "troll blogger". Seriously, this is one of the worst names for anything internet or technology- related that anyone could possibly come up with.

Please please please make sure that someone else chooses the name of the next startup you work on.</comment>


JavaScript Grows a Mustache - <AUTHOR> http://github.com/janl/mustache.js

<comment><USER2> (This response is to JS on the client-side)

Why does the thought of writing view logic in Javascript make me cringe?

I've written very complex client side javascript in the past, and I've become somewhat of a minimalist.

I speak nothing of node.js because I haven't used it, but if this was used on the client side I would barf. If a user is on IE vs Safari vs Firefox, it will perform completely different - which is extremely important when the javascript that is executing renders something to the screen. Users have very little wiggle-room for what they consider "snappy".

IMO, javascript should only be given HTML blocks from the server when rendering larger, more complex partials. This is because if you do it client side (maybe to save the server from rendering HTML and the round trip), you have skattered your view from server-page rendering into javascript CODE. You can test page-renders on the back end, but you need to run a full document emulator (which one, mind you?) to test anything rendered in javascript. I can't count the number of times something in the UI has changed on the backend and we don't find out the javascript fails until later.

I understand the "JS for everything" movement, but I'd be more inclined to bring Ruby into the browser. Javascript is syntax-heavy (especially when creating strings), hard to test, develops slowly, and doesn't provide stack- traces or logs in the event you need to provide end-user support when something goes wrong.

Javascript in my experience is best when used as a conduit - not a swiss army knife.</comment>


Paul Dirac: Projective Geometry and the Origin of Quantum Equations [pdf] - <AUTHOR> https://atomicprecision.com/Topics/Paul%20Dirac%20Talk%20-%20Projective%20Geometry.pdf <comment><USER2> Oddly enough the document lacks any sorts of visual cues.</comment>


A Recession Before 2020 Is Likely - <AUTHOR> https://ntguardian.wordpress.com/2018/04/19/a-recession-before-2020-is-likely-on-the-distribution-of-time-between-recessions/ <comment><USER2> Recession would be caused by the fact that $10 trillion was poured into the economy during the Global Financial Crisis. Yet all this money failed to really stimulate GDP. The reasons it failed are extensive and likely were beyond fixing by any Central Banking policy anyway.

It also was worsened by the fact that likely another $5-$10 trillion is leaking into world's economy, unreported, via opaque Chinese banking regulations and currency schemes. One way this has been deduced is that if you add up all the values of the world's exports and imports...they should equal each other right? But the thing is...they don't, and they're off by trillions of dollars.

td;lr: it's like a person taking steroids for the last 10 years, only bench pressing a few more pounds by the end of it, all the while aging and building disease on the inside. And also they're committing wire fraud.

<comment><USER3> There are over $200 trillion in global stock and bond assets, and over $300 trillion including loans. That should put QE into perspective.

The problem is that the world is awash in cash and not enough interesting- enough investments. OTOH, in no other time in history could a company like SpaceX have existed. OTOOH, companies like SpaceX, Amazon, etc, with huge upsides set the bar really high. Nobody wants to invest in some low-yield market when people believe (rightly or wrongly) they could quintuple their money somewhere else.

It turns out that financial markets aren't anywhere close to being as fluid and efficient as once believed. They're sticky and irrational in all the ways people are elsewhere in the economy.

</comment></comment><comment><USER4> This is really cool and I wish I knew more statistics to fully grasp it.

I can't see what would cause the recession though. Interest rates are only just starting to rise.

Though to be fair if the media says the economy is good then it's time to pull out. If the media says the economy is bad it's time to invest.</comment>


FBI tracks suspects' cell phone without warrants - <AUTHOR> http://www.newsweek.com/id/233916

<comment><USER2> Sprint developed a web application for law enforcement to track people, and they don't require a warrent just a claim that it's an emergency, an 'emergency' constituting things such as labor union protests.

God this is horrible for so many reasons.

</comment><comment><USER3> Title is uninformative: suggest change to the title text of the page, "FBI Tracks Suspects' Cell Phones Without a Warrant".

</comment><comment><USER4> "tape made by a privacy activist who sneaked into the event." Anyone else find this statement ironic?

<comment><USER5> Only if you consider observing "the event" (a government-sponsored security conference, albeit a "private" one) a violation of someone's privacy, I guess. If there's any irony at foot, surely it's your attempt to invoke "privacy" as a defense against exposure of the governments' invasions of privacy.

<comment><USER4> I wasn't really "defending" anything, but whatever. You're the one saying that someone (the privacy advocate in this case) should be able to unilaterally violate someone's privacy, not me.

<comment><USER2> You're the one claiming releasing a quote by Sprint's "manager of electronic surveillance" about how the _company_ Sprint releases private personal information, a statement which the company also confirmed publically on the record, constitutes a unilateral violation of the personal privacy of said "manager of electronic surveillance". Absurd.</comment></comment></comment></comment>


Watch Atlantis rendevous with Hubble Live - <AUTHOR> http://www.nasa.gov/multimedia/nasatv/index.html#

<comment><USER2> I went down to Cape Canaveral to watch the Atlantis launch on Monday.

It was the greatest thing I have ever seen.

I have never felt that much emotion about an event in my whole life.

Only 7 launches are left before they retire the shuttle and I highly recommend you make the trip.

<comment><USER3> From where did you watch? Was it hard to get tickets?

<comment><USER2> From the Kennedy Space Center Visitor Complex. My buddy just ordered the tickets online. I just looked at the website lots of rocket launches as well. Two Atlas 5's in June.</comment></comment></comment>


Google Chrome is ditching its XSS detection tool - <AUTHOR> https://nakedsecurity.sophos.com/2019/07/18/google-chrome-is-ditching-its-xss-detection-tool/ <comment><USER2> Disclaimer: I'm working on the Trusted Types project in Google.

To clarify, Trusted Types are not a replacement for XSS auditor. They are both related to XSS, but are fundamentally different and even target different flavors of XSS.

Trusted Types are an opt-in browser API that helps developers prevent DOM- based (~client-side) XSS by mandating that developer-specified rules are applied to data that reaches risky functions (like eval or innerHTML). We're working on having it available as a proper W3C spec. More info at [https://bit.ly/trusted-types](https://bit.ly/trusted-types) or [https://youtu.be/1KQngEZ8qH4](https://youtu.be/1KQngEZ8qH4)

XSS auditor was an opt-out Chrome only feature that tried to stop reflected (~server-side) XSS payloads from executing after the injection has already happened. It was an now outdated concept. The idea was nice - prevent XSS without changing a bit of code in your application, but now we know this just doesn't work for xss.

<comment><USER3> > _Trusted Types are an opt-in browser API that helps developers prevent DOM- > based (~client-side) XSS by mandating that developer-specified rules are > applied to data that reaches risky functions (like eval or innerHTML). We > 're working on having it available as a proper W3C spec. More info at > [https://bit.ly/trusted-types](https://bit.ly/trusted-types) or > [https://youtu.be/1KQngEZ8qH4*](https://youtu.be/1KQngEZ8qH4*)

Can you expand a little on what Trusted Types gives you if you already have a strict CSP which prevents unsafe-eval/ unsafe-inline and e.g. has a 'self' base-uri set?

I'm assuming it would prevent you injecting other HTML if a DOM-based vulnerability existed.

<comment><USER2> Trusted Types aim to prevent the injection, XSS-y CSP directives (script-src etc) act as an XSS exploit mitigation that fires after the injection is already there. So, for example, even if the JS execution is stopped, the attacker may still exfiltrate the data via form tags etc.

CSP was traditionally deployed by security folks only and is a bit disconnected from the regular dev workflow. For example, if your application does not conform to CSP (i.e. you have an XSS), you can know that only when you deploy it, and the violations keep coming.

TT are part of your JS program, and are much closer to how developers prevent other bugs in their programs. For example, since the API uses types, you can even set up your build for the application not to compile if innerHTML is used with a string.

Additionally, TT allow the application to be a bit more precise - e.g. maybe you can't refactor the application not to use eval() ever (this is surprisingly common), but would rather make sure that this one eval() instance is secure, and disallow all others. TT solve that elegantly. Your reviewed eval starts using eval(TrustedScript), and all other evals - should they exist - are blocked.

In our experience rolling out CSP, its nonced version (w/ no script-dynamic, no unsafe-*) works well for server-side injections, whereas TT cover the client-side better.

[https://github.com/WICG/trusted-types/wiki/FAQ#do-i-need- tru...](https://github.com/WICG/trusted-types/wiki/FAQ#do-i-need-trusted- types-when-we-have-a-content-security-policy)

<comment><USER3> Thanks for a very comprehensive answer!

</comment></comment></comment></comment><comment><USER3> Good. Whilst the XSS auditor was able to protect against quite a wide range of payloads for reflected vulns, I think it caused more harm than good. Quite often I'd have to try and argue that an issue was real because the PoC didn't work in Chrome. Often I was able to find a way you could cause the server to modify the payload such that the browser was unable to match up the input and output, and then the payload would execute - but I think the legacy of this feature is that it has caused developers to take rXSS much less seriously.

</comment><comment><USER4> Interesting! I recently found that Googlebot was susceptible to XSS [1], but it was mitigated by the recent updates (they updated Googlebot from Chrome 41 to the most recent version).

I guess a lot will depend on the new Trusted Types API. If it is opt-in then I imagine there will be period whilst it is adopted - what happens during this time?

[1] [https://www.tomanthony.co.uk/blog/xss-attacks-googlebot- inde...](https://www.tomanthony.co.uk/blog/xss-attacks-googlebot-index- manipulation/)

<comment><USER3> Nice write-up! It's a shame that your report wasn't handled with the usual prompt response & fix.

</comment></comment><comment><USER5> Scary headline; FTA:

> Don't worry, though – another, hopefully better, protection measure is on > the way.

> Another feature is in development to help: an application programming > interface (API) called Trusted Types. Trusted types treats user input as > untrustworthy by default and forces developers to take steps to sanitise it > before it can be included in a web page.

A better headline may be "Google Chrome replacing XSS Auditor with Trusted Types"

<comment><USER3> > _A better headline may be "Google Chrome replacing XSS Auditor with Trusted > Types"_

As I think a Googler has mentioned above, the XSS auditor is for _reflected XSS_ vulns (caused by the server unsafely outputting user input). Trusted Types protects against DOM-based vulns, which are more client-side.

</comment></comment><comment><USER6> > Websites should prevent this kind attack

I've had far too coworkers argue that we shouldn't "waste time" preventing XSS attacks _because_ Chrome already detects and prevents (most of) them.

<comment><USER7> Your coworkers aren't too smart

<comment><USER8> This comment doesn't really contribute anything — and it makes a common mistake of treating this as an issue of intelligence when it's more specific security experience and awareness. In particular, I've seen a pathology around XSS where part of the problem is that someone _is_ pretty savvy and downplays the risks thinking "well, I'd never set things up so that would work", ignoring all of the times they've made mistakes, used a library or vendor product, had projects change hands, etc.

</comment></comment></comment><comment><USER9> It's interesting to hear, knowing the the lack of XSS Auditor on Firefox for years was a recurrent topic on Bugzilla. Even IE and Safari got similar protections. Curious to see if the XSSs I found over the years will now work on Chrome.

<comment><USER2> Well, the age of in-browser reflected xss filters is simply over.

This was a flawed idea for multiple reasons, and they are thankfully now gone from Chrome and Edge ([https://portswigger.net/daily-swig/xss-protection- disappears...](https://portswigger.net/daily-swig/xss-protection-disappears- from-microsoft-edge)). I guess from modern browsers only Safari still has one. There are modern XSS defenses you can use, XSS filters just did not stand well the test of time.

I would state that it is good if your XSS works in Chrome, just like it works in Firefox. That XSS should be fixed by the website, instead of that website owners neglecting the fix and assuming they're protected because the alert doesn't fire in Chrome. Especially given that if the attacker spends a bit of time tailoring the payload, they may bypass the auditor.

<comment><USER10> > That XSS should be fixed by the website, instead of that website owners > neglecting the fix and assuming they're protected because the alert doesn't > fire in Chrome.

What if a website doesn't fix its XSS vulnerabilities and continues to spew attacker-controlled content? I don't think it will help users to base browser security on "shoulds".

I've been taught that security should be built in layers. Removing a functioning albeit not perfect layer for no good reason is baffling to me.

</comment></comment></comment><comment><USER11> From a cursory glance, the replacement (Trusted Types), just seems like a very cumbersome runtime type-safety engine kind of thing, shoehorned into a JS/DOM context.

Is that a correct understanding?

If so... Why use this cumbersome API instead of just relying on existing and well-implemented concepts as already present in Flow or Typescript?

That way you could have Flow or Typescript also compile to whatever form this required to have.

Or am I missing some key bits here?

<comment><USER12> This isn't a programming language type safety mechanism, it's a way to tell the browser to enforce that you can't run code that could potentially be vulnerable to XSS, except in specific places that you designate with policies. This example was illuminating for me: [https://developers.google.com/web/updates/2019/02/trusted- ty...](https://developers.google.com/web/updates/2019/02/trusted- types#trusted-types)

<comment><USER11> Tomato/tomato.

You are effectively saying that only certain _types_ of strings and DOM structures are allowed on certain properties and attributes.

This is perfectly encodable in a type-system. I don't see a reason to dismiss that observation outright.

</comment></comment></comment><comment><USER13> I learned about Xss mitigation 3-4 years ago through google gruyere, a tutorial that came with a sandboxed environment to practice in [1]

Where did others learn about XSS mitigation? Any resources to recommend?

[1] [https://google-gruyere.appspot.com/](https://google-gruyere.appspot.com/)

</comment><comment><USER14> The title is wrong. Google's not ditching anything, it seems.</comment>


Show HN: Upstream – Stream processing, for humans - <AUTHOR> https://www.upstreamapp.io/ <comment><USER2> Being a sysadmin and being interested in monitoring systems, I know quite well where and how to apply stream processing as a general paradigm. Having this "stream-processing-as-a-service", I don't have even the slightiest idea where it could be useful. The fact that the service only provides webUI for defining things, and thus the processing capabilities are very limited, doesn't help.

<comment><AUTHOR> I'm curious, when you say a limited set of capabilities, what libraries or systems would you juxtapose us with?

Our large goal was to make the sharing and collaboration piece much easier than other systems allow for. So let's say that one person might be responsible for instrumenting a system, but others want to be able to create their own notifications or visualizations. One user can publish a stream of events, and then allow others to subscribe and create their own transformations/visualizations. There are other pub/sub systems that achieve a similar result, but generally access control doesn't exist and usually lacks any real system of discover-ability. In the same way that github/bitbucket/etc make repositories easier, we wanted to enable a similar effect with streams of data. And in the same way, we built in a number of tools that make manipulating or visualizing a stream of data easy without leaving the system (sure, you shouldn't probably do the bulk of your code editing out of github's text editor, but it's very handy for quick changes).

I'm not sure if that helps frame our system better. We're still working a bit on how to position the system, so we might even try and revise our landing page to emphasize this more.

<comment><USER2> So your service basically provides (a) place where one can send data for further processing, (b) place where one can process data that was collected, (c) tools for plotting and charting available data, and (d) tools for sending alerts on available data. And registry with available data streams.

Mind you, access control is most probably not a feature for _your customers_ , but for _your company_. Limiting data visibility for employees is usually unnecessary for smallish businesses, and big businesses rarely take part in developing somebody else's product like this.

With all this, I would say that you are like AMQP broker, except you have a stream registry, can do a little of trivial data processing (handful of set functions on a window), have a charting UI, and no way of extracting data back, from what I've seen in the documentation.

And you asked what I compare your service with. These would be Splunk and Riemann from finished software, and in terms of processing capabilities, plenty of stream processing systems invented in academia, like Aurora.

</comment></comment></comment><comment><AUTHOR> Hi folks, I'm one of the creators of Upstream. We'll try to be around all day to answer any questions you might have. We're feeling pretty nervous, but excited to get your feedback!

<comment><USER3> I'm one of the creators too. We're excited to see what you think.</comment></comment>


Free iPhone pits premium brand against Android - <AUTHOR> http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2011/11/04/BUNT1LQA37.DTL&type=tech <comment><USER2> It's not free at all if you have to sign a contract. When obtaining a phone under contract I always consider the total cost of ownership (which is conveniently written into the contract where I live at least). So if you're paying $50[1] a month over 24 months then the total cost is really $1,200. Then I consider if it's really worth skimping on $300 (25% in this case) upfront then not having a better phone. Or I might compare it to the cost of buying a phone outright and how much I'm likely to spend over the next 24 months on a non-contract plan.

[1] Prices are not actual, but are close to what I recall when I last signed up on a contract.

<comment><USER3> Yes and no. Often (almost always?) the price per month would be $50 whether you take a free phone or use your old one. Cash grab by the networks of course, but still. The different is contract length- if you want a phone it's two years or more. But if you intend on having cell service for the next two years (and who doesn't?) it doesn't seem like such a big factor.

<comment><USER4> Rubbish. Most networks have a special contract specifically for iphone users who get a phone. It costs a small fortune more than the contract for other phones. You can also buy a simcard only contract that includes no phone - again, cheaper.

<comment><USER2> I just looked at Telstra's plans for iPhone in Australia and you can get the base model iPhone 4S for $63 a month or the 64GB model for $72 a month. An Android phone will cost you at least $59 a month on a contract but there are also handset repayments involved. Granted this is our more expensive carrier but the only one you can really rely on for coverage outside the main cities.

</comment></comment></comment></comment><comment><USER5> I guess people aren't able to do enough arithmetic to figure out that the monthly bill over the lifetime of a two-year contract swamps the $200 you have to pay upfront for a far more capable device. Caveat emptor.

As an iOS dev I'm a little sad that I'm going to have to keep that low a common denominator in mind for the next few years though.

<comment><USER6> That's not necessarily the case. $200 is still $200. They pay the contract regardless. The same argument could be made about only getting the high end 64GB iPhone since $399 is a drop in the bucket compared to your contract.

Or cable boxes. I assume that you have a top of the line TiVO rather than using what the cable company offers? Cause the upfront cost of the TiVo box is dwarfed by your long term cable bill.

Some people just have different priorities.

<comment><USER5> It looks like the absolute minimum you're going to spend on a 2 year contract is about $1300. You get tremendous bang for your buck for the extra 15% (or much less) a new iPhone 4S will cost you.

I've never thought cable was worth the money so I can't say if a similar logic applies there.

</comment></comment></comment><comment><USER7> These have been around in England as well for at least the last month or so - "free iphone 3GS for just $15/month". I find it incredibly oxymoronic and hence annoying, and I'd really like to see them told to change their language. "Free iphone with a $15/month 2-year contract" would be a lot less misleading...

<comment><USER8> In Finland the carriers are forced, by law, to tell you what to the total cost for the contract will be over it's lifespan. They also have to tell you how much of that total cost is for the phone.

</comment></comment><comment><USER9> Here in South Africa, all phones are "free" on a contract. The important bit is how much you pay per month for the contract.

</comment><comment><USER10> Follow this logic:

1\. for over 12 months big US carriers have been offering free androids with 2 years contract signon.

2\. Samsung has the top selling smartphone in the US despite 4s numbers..

3\. iphone release and Jobs dies.

The article is lacking in logic and few other points

</comment><comment><USER11> Given how fashion-driven Apple products are, who'd want an iPhone 3GS?

<comment><USER12> When I hear people talk about wanting an iPhone, I hear them talk about how they'll use it, not about the fashion aspect. I mean, no doubt some people want it as a status symbol, but it's not at all clear to me that that's "why people want an iPhone".

<comment><USER11> Most of the people I know who had an iPhone 4 sold it for a 4S. I don't think it was so much a Siri thing (it doesn't work very well in Greece).

<comment><USER12> This seems to prove my point, since they look identical. :)</comment></comment></comment></comment>


NES Emulator in Javascript - <AUTHOR> http://benfirshman.com/projects/jsnes/ <comment><USER2> Tried it on different browsers, and wow, this is an alternative way to check the efficiency of the javascript-engines.

Opera and Chrome comes best out so far, with a steady 57-59 FPS. Safari says it comes with 30-33 FPS, but stopped rendering. It still emulated the game fairly well though. I heard I died from a mushroom @ the super mario bros emulator. Firefox had a measly 4-5 FPS.

I tried it with Internet Explorer as well, but it wouldn't start without the sound-engine made in flash. Obviously installing flash for IE isn't that easy, so I didn't bother.

<comment><USER3> It doesn't work at all in IE. It's not anything to do with flash, rather, IE's lack of support for canvas. It gives a JS error on page load (object doesn't support this property or method), on line 28 where it tries to call Canvas getContext.

</comment></comment><comment><AUTHOR> If you were to convert the nes asm into javascript how much faster would it run?

<comment><USER4> Insanely, insanely fast. I created a fork of <http://6502asm.com/> that dynarec'd 6502 machine code to Javascript and cached the functions; the speedup was on the order of 25-100x, depending on the code in question. I used to have it hosted, but it's since disappeared; let me go throw it on github.

Edit: It's up at <http://github.com/daeken/Dyna6502Asm> now. If someone could actually host it so that people can test it out, I'd greatly appreciate it. I'm writing up a small document on how it works, for those who are curious; it'll be in the repo in a few minutes. Oh, and I believe that this was the first dynarec'd emulator for Javascript; this was back in December 2008.

Edit #2: Strategy document is up, here: <http://github.com/daeken/Dyna6502Asm/blob/master/strategy.md>. The same exact mechanisms should work just fine with this emulator, if someone is so inclined. One thing you ought to do, though, that I never got around to, is adding a simple checksum to the code cache. When you attempt to execute a block, check to make sure that the code in memory is the same as the one in the code cache; if it's different, then the code has been modified and needs to be recompiled.

Edit #3: Thanks to icefox, I now know how to host on github! <http://daeken.github.com/Dyna6502Asm/>

<comment><USER5> That's AWESOME.

I think I remember seeing this last time JSNES had some exposure. I'm going write support for this right now...

<comment><USER4> Let me know how it goes. If you run into anything, shoot me an email or hit me up on IRC: Daeken on freenode.

</comment></comment></comment></comment><comment><USER6> I wonder, are all those NES which can be played there public domain?

<comment><USER7> No. They aren't "abandonware" either, as many of them can still be bought for the Wii's virtual console.

The Emulator is pretty impressive, though. Especially the sound emulation/output - iirc the JavaScript Audio API has no "direct" way to play arbitrary wave forms. I guess it uses the data URL scheme and a simple WAV header!?

<comment><USER8> Actually it uses a small Flash app to generate the sound (see the News section at the bottom of the page). I wonder if data URLs could be used like that though?

<comment><USER5> I tried that, but unfortunately data URLs are far too slow. Firefox 3.7 has some exciting audio APIs though:

<https://wiki.mozilla.org/Audio_Data_API>

I've been meaning to write a JSNES prototype for them.

<comment><USER8> Thanks, looks like a very useful API. In addition to synthesizing audio it also has the ability to do spectrum analysis: <http://vimeo.com/8525101>

</comment></comment></comment></comment></comment><comment><USER9> Yay Bubble Bobble!

But seriously, what's with Firefox canvas being so much slower than Chrome?

It can't be javascript speed because Firefox is just as fast as Chrome for JIT JS performance.

<comment><USER5> Long story short: Firefox is just slow. It's tracing engine doesn't cope with heavily branching code like that in an emulator, and it just falls back to interpreting it. It's nothing to do with the canvas. (In fact, Chrome's canvas is far slower than Firefox's.)

Chrome is wildly fast because it compiles everything to machine code instead of JIT compilation.

</comment></comment><comment><USER10> This is awesome. Even Konami code works in Contra!

</comment><comment><USER11> Hope Simucal sees this. Sounds like he was working on an NES emulator 1/2 yr ago. They can probably team up.

</comment><comment><USER12> Cool. How do you do the sound in javascript?

<comment><USER13> I did not looked deep enough, but there's a swf file called jssound.swf in the codebase.

EDIT: Well, from the index.html:

"It has been in the pipeline for a while, but JSNES can now play sound! There is no way of playing dynamically generated sound in JavaScript, but I have created a tiny Flash application reads a buffer from JavaScript then writes it to the sound card."

<comment><USER12> ok cool. yes pure javascript sound has always been elusive.

</comment></comment></comment><comment><USER14> so laggy, can't play it on my laptop.

<comment><USER15> On my 2 year old laptop on Vista + Chrome 5beta, it runs just as fast as it did when I played it sitting at a TV screen eons ago. It's really quite impressive.

... or, rather, it's really quite depressing once you realize this is 25-year- old technology finally making its appearance into (some!) browsers without requiring plugins.

<comment><USER6> Why is that depressing? I find it amazing and exiting.

<comment><USER16> Why do you find it amazing? I saw this first probably 10 years ago with java applets. Is it more amazing because applets are unfashionable?

<comment><USER3> No, it's because Applets, like Flash, are a narrow, specific, proprietary setting. Nobody has ever questioned that Java can handle something like that.

The interesting part here is that it is showing that browsers and JavaScript, with a very different approach than Flash or Java, can now handle this sort of computationally intensive, graphics intensive application without any OS- specific plugins.

<comment><USER17> > computationally intensive, graphics intensive application

Wake me up when that means something from only 5 years ago and not 20.

<comment><USER18> I suspect a pure Javascript Gameboy Advance emulator is not too far off :P

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> guess this kills my nacl port.

</comment><comment><USER20> I tried to play it but it is not taking input from keyboard

I am using ubuntu 9.10 and the default firefox.</comment>


China's Uighur Camps Swell as Beijing Widens the Dragnet - <AUTHOR> https://www.wsj.com/articles/chinas-uighur-camps-swell-as-beijing-widens-the-dragnet-1534534894 <comment><USER2> > "why do you believe in religion, there is no God"

This is why tolerance is so important. When there is no tolerance, then people will justify anything.

</comment><comment><USER3> Note that this practice reproductively sterilizes the Uighur population rather effectively.</comment>


Stali: A new static Linux distribution - <AUTHOR> http://sta.li/ <comment><USER2> ( Also discussed previously at [https://news.ycombinator.com/item?id=8819085](https://news.ycombinator.com/item?id=8819085) and [https://news.ycombinator.com/item?id=7261559](https://news.ycombinator.com/item?id=7261559) )

Interesting points:

* [http://sta.li/filesystem](http://sta.li/filesystem) \-- Everything not obviously covered by a fairly simplified hierarchy is put into /sucks , without fixing the problem of /etc still being a grab-bag miscellany.

* [http://sta.li/filesystem](http://sta.li/filesystem) \-- /dev being for devices is a "Linux assumption".

* [http://sta.li/filesystem](http://sta.li/filesystem) \-- There is no /usr/local .

* [http://sta.li/filesystem](http://sta.li/filesystem) \-- /.git goes unmentioned. (-:

* [http://sta.li/filesystem](http://sta.li/filesystem) \-- Half a decade ago, it was claimed that it has no /lib . This is contradicted here.

* [http://dwm.suckless.org/](http://dwm.suckless.org/) \-- "Because dwm is customized through editing its source code, it's pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions."

* [http://sta.li/installation](http://sta.li/installation) \-- Installation uses HTTP to fetch a boot volume image.

* [http://sta.li/installation](http://sta.li/installation) \-- The actual installation steps of the doco are "TODO".

* [http://sta.li/technologies](http://sta.li/technologies) \-- The Korn shell is the default.

* [http://sta.li/technologies](http://sta.li/technologies) \-- uses Gerrit Pape's runit, tinydyndns, and socklog

* Commentators a few years ago assumed no kernel modules or initrd. There isn't "official" word on this, however.

* Nor is there official word on PAM, which logically falls foul of a _no dynamic linking_ philosophy too.

<comment><USER3> > [http://dwm.suckless.org/](http://dwm.suckless.org/) \-- "Because dwm is > customized through editing its source code, it's pointless to make binary > packages of it. This keeps its userbase small and elitist. No novices asking > stupid questions."

The worst thing about that attitude is that the suckless programs I tried are full of bugs and usability problems. I actually liked the idea of building simplified core programs, without the bloat and bc stuff of the environment around them, and thus opted to use st with a multiplexer. But if the result is that one has a terminal where you can't copy stuff properly because it does not handle linebreaks, or where you can't use ssh properly because the moment you scroll all text gets distorted, that is not excellence, it's just bad. And if they had more users they maybe would find those bugs, and get the help they seem to need.

And the whole "we are cool, we configure in source code" is just lazy. It's not like they gain anything from that, the spared lines of code pale in comparison to the effort needed to organize the configuration at distro level.

<comment><USER4> > And the whole "we are cool, we configure in source code" is just lazy.

Right. A little config file parsing library does not harm (and can be just copied into the project) but goes a long way for user experience.

Look at icewm, one of my favourite software projects. Yes, it's written in 60K lines of C++, but it's rock solid, fast and flexible. The configuration mechanism is powerful and an example of "no bullshit" design.

<comment><USER3> I just wish icewm had a more active project. I reported a bug and never got feedback, it also was never fixed. But yes, apart from that it is a great WM, and especially the configuration is what makes it great. My choice as well.

</comment></comment></comment></comment><comment><USER5> I really like the idea of static linking.

Then I think about how I'd patch the next inevitable openssl bug.

Then I don't like it as much.

<comment><USER6> I guess the "suckless" answer would be to not use OpenSSL.

<comment><USER7> Who knows, we might soon get SuckleSSL. :)

Jokes aside, they have a bizarre philosophy and attitude, especially when you consider their software is most of the time buggy, and… Well, sucky.

<comment><USER8> It's hard to take them seriously when they include statements like this on their FAQ: "Of course Ulrich Drepper thinks that dynamic linking is great, but clearly that's because of his lack of experience and his delusions of grandeur."

</comment></comment></comment></comment><comment><USER9> "FHS sucks" \- and then they make an even worse hierarchy. at least modern distros moved all distro-contents to a single /usr (possibly read-only, snapshoted, etc) mount point.

#suckmore

<comment><USER4> I don't know what a good hierarchy is, but with symlinks it should not be so important where the mountpoints are. So why not keep opportunities to split distro contents into convenient directories living under "/"?

Also separating writable from read-only content, or having volumes with different performance characteristics, makes sense in certain situations. Why not have these mountpoints directly under "/"?

<comment><USER9> When distro-packaged content is in /bin and /sbin (and /lib, /usr etc), you can't easily have those 4 directories in a single image that you can atomically handle (upgrade, snapshot, mount, share, etc) and you must have them together on the /.

That's why Android has /system, and Linux has /usr now. ([https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...](https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/)).

Ideally, and we are getting there, / should be tmpfs/rootfs, it's populated with the needed structure by the initramfs, the distro is mounted on /usr (readonly squashfs perhaps?), user data is /home, system data is /var, configuration is /etc. And the system should boot with empty /home /var and /etc ideally. Soon...

<comment><USER4> If you want all in one file system, make symlinks. Problem solved.

</comment></comment></comment></comment><comment><USER10> I'm confused about some claims / justifications. For example:

> A user can easily run dynamic library code using LD_PRELOAD in conjunction > with some trivial program like ping.

No... Not sure if it ever worked, but it's definitely not possible for many years now.

Also the link to the ASLR effectiveness paper was valid in 2004. That means they're still testing 32bit systems and effectively say scanning 64bit systems the same way is unfeasible.

<comment><USER11> Yeah, that's outdated, but there have been a few related bugs in the dynamic linker not that long ago, like LD_AUDIT: [http://seclists.org/fulldisclosure/2010/Oct/344](http://seclists.org/fulldisclosure/2010/Oct/344)

</comment></comment><comment><USER12> I love the "suckless" philosophy [1], and I'm glad that Stali sticks explicitly to it.

[1] [http://suckless.org/philosophy](http://suckless.org/philosophy)

<comment><USER13> Too bad it prodyces buggier, _suckier_ code.

</comment></comment><comment><USER14> > _" Follow the suckless philosophy"_

I used to love the idea of the suckless philosophy, until I forked `st` to make it work on OS X by removing globals and by separating the terminal emulator logic from the X11 logic, and asked[1] on the mailing list if they'd be interested in merging my changes. The responses I got made me never want to use any suckless software ever again.

[1] [http://lists.suckless.org/dev/1408/23366.html](http://lists.suckless.org/dev/1408/23366.html)

<comment><USER15> Wow that was really disheartening to read. Definitely didn't expect that level of childishness.

</comment></comment><comment><USER16> I thought we were happy to leave behind static linked OSes back in the 90's, other than targeting embedded deployments....

<comment><USER17> One of the first things I read was support for arm and RPi so I assume it's targeting the IoT.

<comment><USER18> RPi is used for a lot more than IoT.

</comment></comment></comment><comment><USER19> Shocked that it takes a fringe project to be promoting static linking and cleaning up the filesystem.

Would love to hear the linux grandfathers chime in...

<comment><USER20> Static linking is a virtue now? I don't understand the advantages.

<comment><USER6> Google Go and Rust promote it. However, deploying web services is different than Linux distro.

<comment><USER21> I don't know about Go, but Rust doesn't promote it. Rust compiles a whole binary at once (for full program optimisation), but that binary can be a dynamic library or executable. How you then build the operating system on top of that is up to you.

<comment><USER6> Recently, ripgrep was on the frontpage. It says "Linux binaries are static executables" [0]. If I run ldd on cargo, it spits out the usually glibc dependencies, but Rust libraries are statically linked. It seems to be the default behavior of cargo? I would describe that as "promote static linking".

Personally, I don't judge this as good or bad. There is no simple answer. Static linking has clear disadvantage wrt security patches. On the other hand, it makes little sense to dynamically link tiny libraries, e.g. a queue data structure.

[0] [https://github.com/BurntSushi/ripgrep](https://github.com/BurntSushi/ripgrep)

<comment><USER22> > It says "Linux binaries are static executables" [0].

They are. Running `ldd` on cargo doesn't confirm or deny this. You need to run `ldd` on the binary distributed:

        $ curl -sLO 'https://github.com/BurntSushi/ripgrep/releases/download/0.2.1/ripgrep-0.2.1-x86_64-unknown-linux-musl.tar.gz'
        $ tar xf ripgrep-0.2.1-x86_64-unknown-linux-musl.tar.gz
        $ ldd ./ripgrep-0.2.1-x86_64-unknown-linux-musl/rg
                not a dynamic executable

This is not the default output on Linux. You need to compile with musl instead of glibc: [https://news.ycombinator.com/item?id=12565268](https://news.ycombinator.com/item?id=12565268)

</comment></comment></comment></comment></comment></comment><comment><USER23> I still don't understand why systemd sucks

<comment><USER24> That's a loaded question, and I'm only qualified to answer from my perspective and experience. My biggest gripe with it has always been that it is alpha- quality software, even today, that has a central role in an otherwise mature OS ecosystem. It has been widely adopted (some would say forced or tricked into adoption by a few distros) and therefore all the major Linux distributions are now running at an alpha level while its creators try to figure out exactly what they want it to be. That was the state of Linux in the late 90s, a state that it overcame during the 2000s, but now it's regressing again.

First it was "just an init to replace SysV", something I could get behind, and back in 2012 or so I was actually excited about it. Then it started growing, replacing individual components of GNU/Linux with a monolithic mega-app that has more in common with Windows NT based OSes than with anything UNIX-like. Gone is the philosophy of "do one thing and do it well", replaced with "do everything no matter the quality of the results".

I've always been a Slackware user since I started messing with Linux in the late 90s, and these days I find it getting faster and better while mainstream Linux distros slow down and grow more and more bugs. One of my benchmark systems for observing the growing bloat of modern OSes is an Atom based netbook from around 2010. It shipped with Windows 7 Starter, which it ran acceptably but not great.

Recently I tested Windows 10, Slackware 14.2, Ubuntu 14.04, Ubuntu 16.04, Debian unstable, OpenBSD, and Elementary OS Loki on it. Slackware was the fastest OS on it by a wide margin, followed by OpenBSD, then Debian, Ubuntu 14.04, Elementary, Windows, and Ubuntu 16.04 dead last. Guess which of those (not counting Windows) do not have systemd? Yep, Slackware and OpenBSD. Maybe it's a coincidence, but given how Ubuntu 16.04 on my modern workstation gets progressively slower with each systemd update, whereas Slackware on the same machine continues to chug along with no issues, that's telling.

All of that said, systemd was and maybe still is a good idea, if only they can stop trying to reinvent the wheel and instead fix the spokes they broke along the way. I can't say I'm happy about eroding the UNIX philosophy from Linux, but if systemd is the future of Linux then it damn well needs to be a stable future.

<comment><USER16> The irony of the eroding the UNIX philosophy from Linux is that most real UNIX systems, meaning AIX, HP-UX, Solaris, NeXTSTep (cough macOS), Tru64,... do have something similar to systemd.

Sometimes shouting "UNIX philosophy" in GNU/Linux forums reminds me of emigrants that keep traditions of their home countries alive that are long out of fashion back home.

<comment><USER25> commercial unixes haven't been relevant for decades. Unix is linux these days.

<comment><USER26> How about the second largest desktop OS in the world, OS X (or now macOS)? That's BSD.

<comment><USER27> OSX is actually a certified UNIX [http://www.opengroup.org/openbrand/register/](http://www.opengroup.org/openbrand/register/)

<comment><USER28> and systemd was modelled partially after its launchd

</comment></comment></comment></comment></comment></comment></comment><comment><USER29> Hasn't stali been around for at least a little while now? I don't think "brand new" is quite right :)

Looks like a neat distro, though. It's been on my bucket list to try.

</comment><comment><USER30> Sucks less until it starts to suck more. It's religion not science. Classic NIH.

<comment><USER11> Nonsense. They have a clear philosophy on what makes software suck less, it doesn't matter where it comes from.

[http://suckless.org/philosophy](http://suckless.org/philosophy)

<comment><USER30> Exactly my point. Philosophy has its place in software engineering but often it's not on a pedestal.

<comment><USER11> I was responding to the "NIH" comment. It's not NIH syndrome if it doesn't matter where it comes from.

 _Philosophy has its place in software engineering but often it 's not on a pedestal._

That's a philosophy in itself, as is pragmatism or adherence to science. You just happen to disagree with theirs.

<comment><USER30> Meh. I don't buy the "moderate valuing of philosophy is a philosophy" argument. If everything is a philosophy then nothing is a philosophy.

My point is, suckless products can actually suck despite following their "philosophy." It's not only the UI, although strictly adhering to the "UNIX" philosophy has its flaws. No, it's the suckiness of the source code that I'm talking about, e.g. dwm is composed of ad-hoc internal abstractions and special cases based on arcane X11 WM domain knowledge, not to mention the suckless comment "philosophy": that comments are a sign of bad code therefore don't use them.

Their "philosophy" is narrow-minded and overly simplistic, like a religion. It's also not based in truth, just biased anecdotes, e.g.

 _" Most hackers actually don't care much about code quality."_

...What? Is there a source for this information?

Their "philosophy" only makes sense for the smallest toy programs. Notice how there is no suckless kernel, It would likely be a heaping pile. Dogma loses, science wins.

<comment><USER31> > Meh. I don't buy the "moderate valuing of philosophy is a philosophy" > argument. If everything is a philosophy then nothing is a philosophy.

Nope, all ideas are philosophy. Just as all matter is made up of atoms. You can't escape philosophy no matter how hard you try.

<comment><USER30> Except "all matter is made of atoms" has been empirically shown and is scientifically consistent, whereas "all ideas are philosophy" is just meaningless abstract gibberish. It's not the same.

<comment><USER31> Luckily pragmatism really is a philosophy, with an actual documented history. Is that scientific enough for you?

<comment><USER30> It doesn't matter. Engineering disciplines don't need a philosophy. Imagine if bridge builders had bridge building philosophies. It's nonsense.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER32> _20160825 stali for RPi stapi.img.gz available for download_

Now for Raspberry Pi, it appears if my decryption is correct.

</comment><comment><USER33> This project has been around for a while.

</comment><comment><USER34> There is a video with the recent changes.

[http://suckless.org/conferences/2016](http://suckless.org/conferences/2016)

[http://dl.sta.li/slcon/2016/slcon-2016-12-agarbe- stali_learn...](http://dl.sta.li/slcon/2016/slcon-2016-12-agarbe- stali_learnings_and_beehive_observation.webm)

</comment><comment><USER35> > Achieve better memory footprint than heavyweight distros using dynamic > linking and all its problems

If this is really effective in reducing executable size, it's supremely ironic, since the original point of dynamic linking was to reduce the overall size of groups of executables by sharing common function libraries.

<comment> loup-vaillant More likely, they're saying mainstream distros are so bloated even dynamic linking can't save them: dynamic linking does reduce memory footprint, but that only _mitigates_ bloat.

<comment><USER36> I think that "dynamic linking and all its problems" imply that some of the bloat comes from the dynamic linking itself. At least that's how I read it.

I believe argument here goes beyond the sole fact of introducing dynamic linker and includes the fact that dynamic linking may encourage duplication of functionality in applications ending up in bloated system (on the other hand static linking doesn't seem to do anything to discourage bloat).

<comment> loup-vaillant I've read around here that static linking allow compilers to remove dead code (unused symbols) from the relevant libraries. The same cannot be done for shared libraries, because you never know which symbols are unused —if any.

</comment></comment></comment></comment><comment><USER37> Why is static linking supposed to REDUCE memory usage and binary size? Am I missing something really obvious?

Eg, if five different binaries are statically linked against the same version of OpenSSL, won't it be in memory and on disk four times more than it would be on a dynamic system?

<comment><USER6> Many applications only use parts of libraries, then the linker can throw the unnecessary parts away.

<comment><USER38> How do I get it to do that?

      $ cat test.c
      #include <stdio.h>
      int main() { printf("Hello, World!\n"); }
      $ gcc -o test1 test.c && ls -lgG test1
      -rwxr-xr-x 1 6712 Sep 28 10:24 test1*
      $ gcc -static -o test1 test.c && ls -lgG test1
      -rwxr-xr-x 1 800904 Sep 28 10:24 test1*

<comment><USER39> I always use dynamic linking but I thought it'd be fun to try making a small, static hello-world. The following assumes x86-64 Linux (and is a total hack that "works for me" NO WARRANTY!).

        $ cat test.c
        static int sys_write(int fd, const void *buf, unsigned long n)
        {
            asm("mov $1,%rax; syscall");
        }

        static void sys_exit(int status)
        {
            asm("mov $60,%rax; syscall");
        }

        void _start(void)
        {
            char s[] = "Hello, World\n";
            int r = sys_write(1, s, sizeof(s) - 1);
            sys_exit(r == -1 ? 1 : 0);
        }
        $ gcc -nostdlib -static -o test test.c && ls -lgG test
        -rwxr-xr-x 1 1480 Sep 28 11:47 test

More to the point of your question, if you want to see the effect you're looking for, I think you need to link to a libfoo.a library that includes some module.o that your program doesn't use.

<comment><USER39> I like this one even better:

        $ cat test.c
        void _start(void)
        {
            __asm__(
                "movabsq $6278066737626506568,%rax\n\t"
                "movq %rax,-32(%rsp)\n\t"
                "movl $1684828783,-24(%rsp)\n\t"
                "movw $10,-20(%rsp)\n\t"
                "movq $1,%rax\n\t"
                "movq $1,%rdi\n\t"
                "leaq -32(%rsp),%rsi\n\t"
                "movq $13,%rdx\n\t"
                "syscall\n\t"
                "movq $60,%rax\n\t"
                "movq $0,%rdi\n\t"
                "syscall");
        }
        $ gcc -nostdlib -static -Os -o test test.c && strip test && ls -lgG test
        -rwxr-xr-x 1 864 Sep 28 14:22 test

864 bytes! :)

</comment></comment></comment></comment></comment><comment><USER40> Has anyone actually tested the claim of static linking improving performance?

The dynamic linking might not be free in terms of cycles but a huge part of the code is already in memory rather than on disk at the time the binary starts.

</comment><comment><USER41> Is there any work on ASLR for quasi-static binaries? So you have no external linking (good for distribution and unsurprising dependencies), but still relocate at runtime.

<comment><USER10> In stali, or in general? For stali there's a slightly confusing FAQ entry: [http://sta.li/faq](http://sta.li/faq) / "Aren't statically linked executables less secure?"

> it is simple to use position-independent code in static executables and > (assuming a modern kernel that supports address randomization for > executables) fully position-independent executables are easily created on > all modern operating systems. [...] Thus we consider this as an issue with > low impact and this is not a real focus for us.

So I don't know if they do it or not. If I read it correctly, they just ignore something they say is easy to do.

But in general, as mentioned, there's normally nothing that prevents you from compiling PIE C code even if you use -static.

<comment><USER42> I'm assuming that even with PIE, the relative positioning of the statically linked libraries is constant. That means you only need a single address leak to be able to ROP to anywhere.

<comment><USER10> That's how I understand it as well (it's a single rel/ro segment). But then again, in most cases you only need any address anyway. Rop gadgets are everywhere...

</comment></comment></comment></comment><comment><USER43> Why not Stalin? Catchier and easier to remember. :-)

<comment><USER44> The name is taken.

[https://github.com/barak/stalin](https://github.com/barak/stalin)

</comment></comment><comment><USER45> Any plans to include i386?

</comment><comment><USER46> It is quite hard to take seriously any project that so much uses word "suck" to describe other projects, i.e., other people work, or their approaches.

<comment><USER47> Why? Most software out there sucks. Computers suck. Most people are unbelievably bad at designing and writing software. Very few of us are RJ Micals or Adam Leventhals, or Jeff Bonwicks. Most people have major issues with reasoning and implementation when it comes to writing software. It's the reality.

<comment><USER48> Ironically, suckless.org is a bunch of plan9 elitists. The plan9 elitists are similar to solaris elitists, but have radically different beliefs, and probably believe that Bonwick and Leventhal and the rest should be jailed for working on ZFS, DTrace, Zones, SMF, etc.

</comment></comment></comment><comment><USER49> Um... Sounds too much like Stalin?

</comment><comment><USER47> _Ignore FHS of Linux, it simply sucks._

Wow. Just wow. So these guys don't understand UNIX. Like they're going to do it better than the fathers of UNIX at AT&T (who came up with the specification on which the FHS is based). Yeah, OK.

 _Achieve better performance than any other x86_64 or arm distribution, as only statically linked binaries are used_

Wow. So not only do they not understand UNIX, but now every process will have memory allocated for every symbol in the ELF header, and any application linking with the same set of libraries will have their own copy of the same machine code, and the startup will be longer, because every application will be larger. Any patching which will need done, all affected applications will need recompiled. Why does this remind me of Windows?

 _Achieve better memory footprint than heavyweight distros using dynamic linking and all its problems_

Yeah, of course! Why try to rack your brains designing versioned interfaces and making sure libraries are backward compatible, when you can just statically link everything and create tremendous overhead in terms of maintenance and security? No point in writing linker map files and having the runtime linker present the correct version of the API to the application, riiiggghhhttt?

Is this a case of more Windows people getting onto the Linux bandwagon, and just completely not getting it, or what?

<comment><USER50> Windows? Have you ever heard of DLLs?

<comment><USER51> My Windows system currently has 21 copies of zlib1.dll on it, each shipped by a different program. While I have no doubt that Windows programmers have heard of DLLs, they clearly haven't grasped the idea of shared libraries.

<comment><USER50> The problem in that case is developers not putting their DLLs in a system directory! Windows will use WinSXS to avoid problems with different versions (DLL hell).

Once loaded into memory, DLLs save loading the same code twice. See [http://www.ksyash.com/2011/01/dll- internals/](http://www.ksyash.com/2011/01/dll-internals/)

<comment><USER2> This hasn't seen an airing in a while, because it became accepted wisdom years ago. You're encouraging a bad design that the world has learned better than to employ.

* [http://jdebp.eu./FGA/dont-put-your-dll-in-the-system32-direc...](http://jdebp.eu./FGA/dont-put-your-dll-in-the-system32-directory.html)

<comment><USER47> _This way, the DLL will be somewhere (usually a "Bin" subdirectory) within the application's own subtree rooted at "\Program Files\company\product\"._

This plainly shows just how poorly thought-out Windows is, to paraphrase:

 _we didn 't design a directory tree like UNIX, and we don't have a proper runtime linker like UNIX, so we are going to swipe using the bin/ directory like on UNIX because we don't know where else to put stuff, and while we're at it, we will rename bin/ to Bin/ because we don't know any better, and also while we're at it, we'll dump all the dynamically linked libraries which the application needs into that mis-named Bin/ directory._

Because Windows doesn't have a proper operating system structure, nor does it have a clean structure (case in point C:\Program Files (x86)\, even if your Windows is 64-bit), nor does it have a runtime linker with the functionality equivalent to ld.so.1 (the only way to get anything close to -Wl,-R/opt/local/lib/64 out of LINK.EXE is to use an XML manifest(!!!), and $ORIGIN keyword's functionality of ld(1) is science fiction for LINK.EXE).

How amateurishly bad can one get? _Wintendo_ is a gift that just keeps on giving...</comment></comment></comment></comment></comment></comment>


Ask HN: How did you supplement income when bootstrapping a B2C startup? - <AUTHOR>

Over the last couple years since I originally started working on the premise for http://gorankem.com , I've held a variety of side/odd jobs to scrape by and keep the vision alive.
Unfortunately, Athens, GA isn't exactly the most conducive setting when you're bootstrapping a B2C startup where the monetization strategy comes with the data collection.
As I alluded to earlier, I've done a wide variety of part-time gigs such as promotional events to small-time consulting to my most recent gig with an 11hr/wk salary social media marketing job.
It was nice to always be able to count on a set amount of income, but they just squeezed the budget, and I was an axillary expense.
Sooo with that said, what's a guy to do that has handled just about every role on the hustler/business side of things?
Where do you go to find consulting work? How do you get off the ground with elance, odesk or guru?
Any other specific suggestions for outlets to generate some income on a part-time basis (even remote opportunities)?
Thanks in advance,
Adam <comment><USER2> Freelancing is not a bad idea, but many developers tell me they inevitably spend more time than they want to on others' projects. Money is pretty good though.

I don't know how much you need to survive, but do something non-coding related to help relax your brain when you're not working on your own idea. I go to Athens a lot so I know the bar scene is crazy there. See if you can get a gig as a bartender. You'll make good money and it'll be fun.

As for odesk, elance, etc. just build an attractive profile highlighting your strengths and bid for jobs you know you can do when they pop up. Simple stuff, but be tenacious.

Good luck!</comment>