Haskell tutorial for C programmers - <AUTHOR> http://www.haskell.org/haskellwiki/Haskell_Tutorial_for_C_Programmers <comment><USER2> Oh my, another tutorial. I've looked at many of them, trying to learn something from the Haskell way. And I think I get the fundamental advantages of the type systems, the lazy evaluation enabled by the languages purity, I think I can somehow make sense of the Monads even. I have the "learn you a haskell for good" on a pile of books where I have a glimpse from time to time.

Most tutorials and books are very enthusiastic in how they can detect that I try to zip two lists of different cardinality during compile time, or how they can lazily calculate the Fibbonacci sequence. And that's really nice and fine...

But nevertheless, I use C all of the time, and I learnt how to make use of a myriad of libraries, combine connections to a SQL database, embedd a webserver, talk to USB,... Must have been 20 years ago that I wrote code to calculate the Fibbonacci sequence.

So, where are tutorials that showcase all the wonderful "high-level" functionality that has already been written for Haskell, so that I, after reading through the text, will be thrilled how much work I can avoid, or how much security I can gain when switching over from my "almost bare-matel not- much-more-like-an-assembler C" to Haskell? Not in calculating the Fibunacci sequency, but in writing a backend for my web-app, or talk to a USB peripheral? Do 3D graphics?...

<comment><USER3> If all you've done is looked at tutorials and glimpsed at a book, I think it's very unlikely that you actually get the advantages or really understand any of the patterns like Monads. _Write some code._ The only way that you'll actually grok the language and get any of the benefits from learning it is if you actually write code in it.

</comment></comment><comment><USER4> Chris Allen / coolsunglasses maintains a great gist of a learning path for haskell: [https://gist.github.com/bitemyapp/8739525](https://gist.github.com/bitemyapp/8739525)

The current intro course looks really nice: [http://www.seas.upenn.edu/~cis194/lectures.html](http://www.seas.upenn.edu/~cis194/lectures.html)

<comment><USER5> This gist was what helped me finally learn Haskell, after failing on my first two tries.

</comment></comment><comment><USER6> @kissthblade: Your comment (dead) below is very sad. You've been hell-banned for more than a year and a half. It doesn't just _seem_ like nobody is seeing your comments, it's true.

For those without showdead on:

"I posted about the same comment as the parent hours ago. I don't know if anybody even sees my posts, never gotten a response, and my "karma" or something has always been 15. And posting and reading the forum is very slow. What gives?"

Looking through your comments, I don't see an obvious reason you were hellbanned.

<comment><USER7> This happened to me, too. I spent about a year replying before finally seeing someone mention I was hell banned. I also wondered why the forum was _so_ slow, but it's not particularly well coded so I just assumed its always been like that.

</comment></comment><comment><USER8> This makes for very good reading indeed. I started reading it and just now realised that I'd spent the last couple of hours on it. It's written well, approachable and very pragmatic. I spent a short while on Haskell a few years back and stopped after 3 or 4 chapters of Learn You A Haskell due to time constraints. I think I'm going to make this my evening reading and finally pick up the language.

Thanks for posting this.

EDIT: typos

<comment><USER9> That's great!

Don't expect to "pick up the language" in an evening :)

Haskell takes a few evenings at the very least!

</comment></comment><comment><USER10> This is great, and I've bookmarked it for reference while reading LYAH. Thanks for writing it.

For anyone who needs a refresher on DFA, Stanford's CS143 compilers class course materials are up on Coursera ([https://www.coursera.org/course/compilers](https://www.coursera.org/course/compilers)), and pretty helpful.

</comment><comment><USER11> >What this means is that existing sort functions such as mergeSort and quickSort would need to be rewritten to sort values of the new type. In constrast, here is the type of mergeSort in Haskell mergeSort :: Ord a => [a] -> [a]

Er, you could define mergesort using templates in c++ and it would work pretty much the same.

<comment><USER12> How do you express the Ordinality constraint in C++?

<comment><USER13> Multiple inheritance from a purely virtual class. In Java, they're called interfaces; Comparable is the analogue to Ord.

The advantage that Haskell's typeclasses have over either Java or C++ is that the types aren't closed. I can define a new typeclass and tell the compiler that a type you defined is a member of that class at any point. In Java, if you don't define that your type is Comparable, there's nothing that I, as a consumer of your type, can do about it.

<comment><USER9> The advantage you mention is one of many (over OOP interfaces), I'll repeat it as (A).

(A) Ability to instantiate old types with new classes

(B) Conditional instantiation: "Maybe a" is an instance of "Show" iff "a" is an instance of "Show"

(C) Can do return-type polymorphism, or polymorphism on any part of the signature

(D) Objects do not need to pay for the interface vtable pointer. Large array of some type-class instance can be much smaller than an array of an OOP interface subclass.

(E) When comparing two Ord instance values, there is only one Ord dictionary, rather than 2 to choose from. No false dilemma.

<comment><USER14> E) you do get a dilemma if you add two elements in a sorted structure , lexically in two different files, where two different Ord instances arr in scope, respectively. this function-is-instance problem is dual to OO's -object-is-instance problem.

<comment><USER9> A homogenous list is guaranteed to only have one instance unless you enable incoherent instances (a known bad extension) or confuse the compiler with orphan instances (though I've never encountered this and think it should be detectable at link time anyway).

One type -> at most one instance for any class, in Haskell.

</comment></comment></comment></comment></comment></comment><comment><USER15> This is great, now I just need a similar tutorial but for LISP.

<comment><USER16> Here's an interactive one:

[http://www.eblong.com/zarf/zweb/lists/](http://www.eblong.com/zarf/zweb/lists/)

Bit dated, though :)

</comment></comment><comment><USER17> Great! A Haskell tutorial for JS or PHP programmers would be awesome.

<comment><USER18> How would it be different? JS and PHP are near identical to C.

<comment><USER14> How do I port closure-heavy prototype-based objects from JS to Haskell? This isn't near identical to C.

</comment></comment></comment><comment><USER19> Uhm ...great perspective!</comment>


Electric cars head toward another dead end - <AUTHOR> http://www.reuters.com/article/2013/02/04/us-autos-electric-hydrogen-idUSBRE91304Z20130204 <comment><USER2> Real problem of electric cars in america. Coming from a person who REALLY wants an electric car:

I live in an apartment. The end. I cannot charge my car like I can with a gas car. I must plug it in overnight, which is impossible since I have no permanent driveway. And even if I did I would not have access to electricity for charging. I also live in New York. Here getting an electric car makes 100% sense, short driving distances, slow speeds, lots of stopping, the ideal environment for electric cars, and yet most new yorkers live in apartments/driveway-less houses not houses with driveways.

And I REALLY want an electric car. The savings would be great, and it would really help with the pollution in the city. But alas, it is not possible.

And of course driving cross-country. I have no way of filling up. It would make sense if I could pay some fee to gas stations to leech their juice while I stop there for say 15 minutes. That would turn any gas station into an electric charging staging, of course that requires the car to charge quickly.

And so the heart of it all: We need a REALLY - REALLY fast charging battery that can go about 100-200 miles. Once you have that, people charging weekly for ~ 15 minutes won't be such a terrible thing. And it's now practical as a car for anyone.

And FFS, we need low-end electric cars. Because super high-end cars like tesla will never get the adoption needed. A flood of low-end electrics would solve the problem of charge stations everywhere.

<comment><USER3> Have you tried something along the lines of an electric bicycle with cargo space, which is allowed on the subway?</comment></comment>


Blockchain-Flavored WASI - <AUTHOR> https://medium.com/oasislabs/blockchain-flavored-wasi-50e3612b8eba <comment><USER2> "Slow Database"-Flavored WASI

 __Any time you see the word "blockchain" replace it with "Slow Database" in your head and see if it still makes sense.

<comment><USER3> Any time you do a generalization, you are wrong.

<comment><USER4> The Blockchain is the slowest and at the same time most energy hungry Datastore mankind has ever build. And in the case of bitcoin it's not fit for the job it was developed for.

<comment><USER5> It was designed to help create a timestamp for blocks of transactions. It's doing that just fine for Bitcoin.

<comment><USER6> There's no way for the blockchain to validate time stamping due to fluctuation in hash power and the nature of an adversarial network with untrusted data.

What's been happening is blocktimes wildly fluctuate, anywhere from 20 seconds - 90 minutes + even though the software attempts to calibrate for 10 minutes.

<comment><USER7> He just means things are unequivoqually ordered in time, so each block is a time stamp. Not necessarily running at constant frequency as our other time keeping tools.

</comment></comment></comment></comment></comment></comment><comment><USER8> The level of negativity received by this article only because it's related to blockchain is almost comical. More so for the fact that the name of the aggregator includes the name "Hacker".

<comment><USER9> Is there something about hackers that would make you expect them to like overhyped technologies that have a very limited set of cases where they're actually a good choice in the real world?

</comment></comment><comment><USER10> "Bitcoin has UTXO+transactions+proof-of-work, Ethereum has accounts+smart contracts+proof-of-work (soon to be CBC Casper), and Oasis has accounts+confidential smart contracts+BFT"

Love how the author plugs his blockchain in that sentence as if it is in the same league as Bitcoin and Ethereum.

<comment><USER11> That's content marketing 101: You write about a general trend and you give a few well-known examples plus your own product. It's very common on Medium and LinkedIn.

</comment></comment><comment><USER12> Putting an experimental systems interface in an immutable blockchain seems like a bad idea. Why not just use linux x86 or Emscripten asm.js or even JVM? That wouldn't get you as many HN hype points I guess.

<comment><USER13> I am still failing to find the reason why they are trying to put 'blockchain' together with everything else these days.

It is exquisite for ledger/proof-of-work systems, but not much else.

Sounds like they're randomly taking guesses at what fits well with what, and the building upon.

<comment><USER14> I don't know much about _this_ particular project, but "wasm + blockchain" is not that silly an idea.

The ethereum crowd is dead set on making the "Web 3.0" thing take off, and getting smart contracts to evolve into full-fledged distributed applications (dapps in the lingo). In that context, the ewasm project is a pretty damn serious attempt at leveraging the wasm specification as a better VM for dapps than what the current EVM provides.

<comment><USER15> It's a better VM, sure, but the core problems are conceptual: there's no way to fix bugs and programs still have to rely on outside sources for triggers. All a blockchain adds is the ability to get VC funding to expensively reinvent the trusted third party but with less efficiency.

</comment></comment></comment></comment><comment><USER16> I don't see the benefits of jamming the square peg of language builtins into such a narrow use case.

> the runtime translates WASI args_get and args_sizes_get

> for the zeroth arg to the blockchain address() function.

There is nothing intuitive about that for me.

In most languages, exposing the blockchain interface as a module feels like it would be a significantly cleaner implementation. If I want to compile against different targets I'd prefer to wrap that module as a library behind my own interface. I can then swap out the implementation at compile time.

<comment><USER17> > > zeroth arg > There is nothing intuitive about that for me.

It looks a lot like how a command-line program has the program name as the zeroth argument. The address just happens to be the name of the program in a blockchain context.

> exposing the blockchain interface as a module feels like it would be a > significantly cleaner implementation

I'm not so sure. I think that the goal here is to allow developers to program "DApps" using their normal toolchain and abstract over the semantics of the blockchain platform. IMHO even the ideas of "block" and "chain" are implementation details in the same way as the journal of a traditional database is an implementation detail. Exposing these details as a library means that the program is tied to not only the blockchain, but a particular blockchain runtime.

> wrap that module as a library behind my own interface

That's always a good idea, but not incompatible with having a lower-level interface (in this case WASI and Rust/C++/AsmScript `std`).

<comment><USER16> > IMHO even the ideas of "block" and "chain" are implementation details in the > same way as the journal of a traditional database is an implementation > detail.

The internals of a database are one thing, but the semantics of the language builtins seem like another. It almost feels akin to someone suggesting we change the underlying implementation of "println" (or whatever language builtin outputs to stdout) to automatically write to a new row in a database. I mean, I could adjust to such a weird idea but my initial impression would be we are forcing an existing abstraction onto a problem rather than choosing a truly suitable abstraction.

> Exposing these details as a library means that the program is tied to not > only the blockchain, but a particular blockchain runtime.

Not necessarily, I'm considering something more like Go's cloud API: [https://github.com/google/go-cloud](https://github.com/google/go-cloud) You could easily have a "blockchain" API with any number of runtime backends.

I understand what the proposer was suggesting: a single semantic meaning for "print" across all programming languages that will map onto blockchain. I just don't agree that it is a good idea.

</comment></comment></comment><comment><USER18> For fuck's sake.

<comment><USER19> Agreed, though what's really fucked up is the native Ethereum language and machine. Almost anything is an improvement on that. I still don't know what to use any of that for though. :-/

Edit: yes I mean Solidity. I mean, it's cool that it works, but look at it, it's insane. They could have picked just about any language, including assembler, Lisp, Lua, Javascript, Visual Basic, LLVM bytecode, whatever and would have been better off. But over time there will evolve compilers which can from another input language provably (-ish in most cases) produce safe output.

<comment><USER20> An EVM smart contract bytecode is usually 2kB - 4kB. You can think it as DSL optimised for its use case.

EOS contracts are 250kB because they suck in C++ stdlib, templates or what not.

There are benefits of having compact bytecode performance wise: cache pressure, price of on-chain storage and so on.

<comment><USER19> But it's not very optimized. It's very low level and you have to add defensive code, taking up space.</comment></comment></comment></comment>


Ask HN: Does agile need innovation or back to basics? - <AUTHOR> Based on the post from few days ago (https://news.ycombinator.com/item?id=18426043) I would say that agile is pretty much making a lot of troubles to tech teams and business teams are still trying to understand it.<p>Do you think we need innovation regarding processes and organizations structure? <comment><USER2> No innovation required. Moving away from the dogma that underlies Agile is. It is necessary to think more "lean" and less "agile", adapt the process to fit the team, not the other way around.

<comment><USER3> Adapting the process to the team is exactly the spirit of "agile". If you switch to a different word like "lean" then shady consultants and vendor snake-oil salesmen will just come along and corrupt it the same way they did "agile".

In reality there isn't a lot of dogma underlying agile. For example, agile has nothing to do with CSM's, story points, Jira, velocity, "sprints", etc.</comment></comment>


Node Version Numbers - <AUTHOR> https://github.com/joyent/node/issues/8104

<comment><AUTHOR> 'This' debate has kicked off over at Node again, on whether a mature, developed project should be versioned in major.minor release numbers, or whether it's acceptable to stick with 0.10.20 and so on indefinitely.

I know there are a ton of developers in HN, so I'm wondering what the community's views are on this debate.

</comment><comment><USER2> What is the big deal in the next version anyway?

<comment><USER3> Here's what's new: [http://strongloop.com/strongblog/whats-new- node-v0-12-featur...](http://strongloop.com/strongblog/whats-new- node-v0-12-features/)</comment></comment>


San Fran is so expensive, some tech companies can't convince employees to move - <AUTHOR> http://www.cnbc.com/2017/04/06/san-francisco-cost-of-living-pricing-out-tech-companies-workers.html <comment><USER2> Costs indicate it is full. Going there is like going to Disneyland when it is over occupancy, too expensive and not enough efficiency at that scale to have a good time. The housing/rental market of SF is screaming "get out", unless of course if you own real estate property.

All SF tech companies promote how with technology you can be anywhere, but apparently there is a single point of failure on physical work locations, or on the flip a nice real estate funnel for above market rates. SF is part tech play part real estate, the smartest investors are investing and collecting the rents of those investments and salaries.

<comment><USER3> > Costs indicate it is full

The city of SF is half as dense as Brooklyn and there are a lot of empty lots here. There is a lot more room for development. The problem is that the current political situation makes it easy for people to block new housing.

As an example - there is a 600-acre empty lot near the Bayshore Caltrain station. The developer wants to build 4400 units. The city wants to build 0 units and build an office park instead. Which will get built? It's not clear - the 5 people voting on it will probably be swayed by how many people show up to the meetings and advocate one position or another. I showed up last Thursday and one city resident said we should not build housing there because an earthquake may cause the buildings to fall over.

You have agency in this situation.

I wrote about this a little more here: [https://kev.inburke.com/kevin/sf- housing-politics/](https://kev.inburke.com/kevin/sf-housing-politics/)

<comment><USER4> The cost signal is what, not why. From the perspective of a potential buyer/renter, it doesn't matter if the cause is "density" or "politics."

<comment><USER3> "Full" is a really meaningless term. It would be pretty easy for rents to rise a further 20%.

I am just pointing out that tech workers are generally apathetic about the housing supply and the local politics, because we can outbid everyone.

At some point the high prices will become a problem for the tech industry as a whole. It's already a problem for me.

I also want to point out that we have agency in this situation; we can lobby for SF supervisors and city council members and state senators that will implement more pro-housing legislation, and we can show up to the meetings where new housing gets denied and lobby for it.

</comment></comment></comment></comment><comment><USER5> Zero incentive to move to SF. The cost of living has reached a point where I'd end up taking home less disposable income even with a significant increase over my current base salary and signing bonuses get eaten up by moving expenses. Barely escaped the housing bubble crash in south Florida a few years back. No way I'd want to run the risk of experiencing another market adjustment.

<comment><USER6> Around 2005 or 2006, I got a call from a headhunter that wanted to shop me out in finance in NYC. Told him I wasn't interested, but he persisted and inquired what it'd take for me to relocate (from Chicago suburbs) and it was simple: triple my salary. I'm not a city person; I like the outdoors (I prefer real wilderness, but plentiful forest preserves around Chicago suffice). I figure 3x was a reasonable figure to do one of two things: either sacrifice my lifestyle to have a reasonable commute or put up with an absurdly long commute to have the lifestyle I wanted. That was the last I heard from that recruiter. I'm not disappointed.

</comment></comment><comment><USER7> I love living in San Francisco. For me, it's a near-perfect city and climate. Obviously it is expensive but I find it completely worth it.

<comment><USER3> Please consider joining YIMBY Action, SFHAC, or other pro-housing groups to try to make/keep housing less expensive.

[https://kev.inburke.com/kevin/sf-housing- politics/](https://kev.inburke.com/kevin/sf-housing-politics/)

<comment><USER8> It may be that one of the things about SF that makes it attractive for OP is that it is expensive. Keeps the riff-raff out. Not that anyone in SF would ever admit that publicly.

<comment><USER3> > It may be that one of the things about SF that makes it attractive for OP is > that it is expensive. Keeps the riff-raff out. Not that anyone in SF would > ever admit that publicly.

This is really inaccurate, and especially discouraging on a message board for "entrepreneurs", who should really be in favor of cheaper housing close to venture capital, so new businesses are more viable.

[https://kev.inburke.com/kevin/sf-housing- politics/](https://kev.inburke.com/kevin/sf-housing-politics/)

<comment><USER9> Is housing in tier 1 cities like SF a giffen good (where demand rises with price)? Possibly [1]. That said, it wouldn't be unique to SF if true and wouldn't detract from your other policy points.

[1] [http://www.businessandeconomics.mq.edu.au/our_departments/Ec...](http://www.businessandeconomics.mq.edu.au/our_departments/Economics/Econ_docs/research_seminars/2008_research_seminars/Onur- CapitalGainsHousingQuasi-giffenGood.pdf)

<comment><USER3> No, it's not. A ton of supply came on the market in 2016 and rents fell 5%.

</comment></comment></comment></comment></comment></comment><comment><USER10> > some tech companies can't convince employees to move

I have outright blacklisted San Fransisco for potential employers. I would avoid travelling to SF even for consulting work for limited duration. I am surprised why tech companies want to setup shop there in first place.

<comment><USER11> Not going to SF even for a limited time sounds a bit extreme. You can rent a cheap AirBnB and buy groceries from Safeway if you really want to control your costs. If its the homeless issue that bothers you, don't stay in SoMa or the Mission. You can actually get around the city for cheap using MUNI. Uber Pool and Lyft are also affordable options.

<comment><USER10> I think it is mostly because of traffic, lack of free parking space and bad roads. I like to drive myself and also have eating habits that require me to visit specific places only.

</comment></comment></comment><comment><USER12> If money is the issue, couldn't they convince them with more money?

<comment><USER13> I know your comment is probably tongue-in-cheek, but that answer sounds like a band-aid at best. More seriously, people who aren't used to spending $15 for a quick lunch and whatever a month on rent aren't going to jump at that opportunity. I moved to New York from Pittsburgh, and paying 3x for rent really took a while to get used to, despite an increase in income that afforded me rent in New York.

<comment><USER14> I don't know if it is a band-aid, rather it is part of the system.

Specifically you're a company and you're trying to hire people to fill roles. If they are are required to be at the company you have to pay them enough that they can live near you.

You set up a series of constraints on hiring:

1) Compensate[0] enough so that someone from outside can enter the local economy effectively.

2) Compensate enough to convince someone who is already in the local economy to change from where they work to working for you.

3) Compensate enough that someone working for you won't go work somewhere else.

Within that system to have to operate a business model where the value you capture in the market has to cover not only your operating costs (which include compensation for the employees creating that value) but allows for you to fund maintenance, depreciation, and some R&D efforts for new product development.

If you can't find a solution set that works you have to improve the business model (generally add revenue or cut costs). Not really rocket science of course.

I keep watching to see if some large presence in SF ends up moving to the east bay or even Reno as a way of changing the cost parameters. If you look at job changing as brownian motion you can watch an environment parameters start to change which results in people (the particles in this case) start changing where they are likely to be.

Personally I would love some quantitative data collection that helped map out the weights of the various factors. It would help predict the next 10 years.

[0] Compensation is also a complex thing, more than just dollars per week/month/year there are things like free food, bus rides, and other services in addition to environmental plusses and minuses and work demands.

<comment><USER15> I think the other complicating piece of compensation is the potential for equity to be worth something someday. It seems to me people in SF are here to take a shot on the startup lottery much more so than other places. It's also a city where you can easily play a few lottery tickets over a few years, which is not the same elsewhere.

<comment><USER14> Absolutely. Although in my experience it is a better deal in an already public company than a startup. Even when the stock is going down if you have an employee stock purchase plan where you can set aside money that will buy stock at fixed times for a percentage discount it can be huge win.

</comment></comment></comment></comment></comment><comment><USER16> I live in NYC right now, but you couldn't pay me 5 times the salary to move to SF. NYC knows how to build housing. While it can be expensive in the newest buildings in the most convenient areas, if you go to the outer boroughs, you can find plenty of spacious housing for decent costs and a 30 min subway ride to Midtown. SF needs density, and fast or they could keep driving out the average citizens. But tech workers probably don't make good firefighters, police, or trash collectors.

</comment><comment><USER17> I was thinking, "no way I'm going to try to move a 5 person single income family to SF on a raise that doesn't cover the difference in cost of living"

Then I realized, I'm almost 40, no startup wants to hire my geriatric ass.

</comment><comment><USER18> I (barely) tolerate the bay area to get to do the work I love. It's a permanent game of weighing pros and cons and doesn't feel sustainable long- term even working at one of the best-compensating companies on the planet.

When 40% of the people in your city want to move away, you know there's a problem.

</comment><comment><USER19> I don't know about the other cities in the table, but a studio apartment in Chicago does not cost $1490 a month. Even downtown you can find a few studios for around $1200, and in the rest of the city it's more like $1000, maybe even less. I live in a 2-bedroom for less than $1490.

<comment><USER20> I lived in Chicago for 8 years. The best decision I ever made was to leave. I moved to Dallas and Chicago is a dump by comparison. San Francisco may be expensive but there are better alternatives (San Diego, Austin, Seattle...)

<comment><USER21> Agreed Dallas is amazing especially with a NYC salary

</comment></comment></comment><comment><USER22> I almost purchased a condo in East Palo Alto back in 2013 for $300K. That same 1-bedroom is now selling for $680K; biggest missed opportunity of my life. Here it is on Zillow:

[https://www.zillow.com/homes/for_sale/East-Palo-Alto- CA/cond...](https://www.zillow.com/homes/for_sale/East-Palo-Alto- CA/condo_type/15636176_zpid/11228_rid/1-_beds/100000-_price/375-_mp/globalrelevanceex_sort/37.491034,-122.104841,37.444982,-122.166639_rect/13_zm/)

There are _no_ 1 bedrooms from Santa Clara to Burlingame for < $350K, and only one two-bedroom for less than $500K.

<comment><USER21> $300k list or $300k all in?

Either way, consider that between buying costs, potential upkeep, selling costs, __property taxes __and capital gains taxes, you probably would not have made out with very much.

</comment></comment><comment><USER23> > And while employees complain about San Francisco's high housing costs, the > city's casual culture means they don't have to spend as much on clothing.

That's...interesting? I always figured this was an industry phenomenon - not a city one.

</comment><comment><USER24> Why is it San Diego never makes these lists? Proximity to LA? Oakland's on there, and it's a lot closer to SF. Doesn't have a thriving tech scene like all of the others? Like Miami?

<comment><USER25> Poorer salaries relative to cost of living. San Diego has what we refer to as the "sunshine tax" so employers feel that they can get away with paying less.

The startup scene is pretty much moribund for the 20-something:

The dynamic people left Qualcomm years ago--it currently resembles DEC or IBM of old.

Med/biotech is long term--if you're a 20-something who wants to get rich that isn't a great path. (Side note; biotech salaries seem to suck--it's part of the reasons why we have so many microbreweries--if you're going to be underpaid doing microbiology anyway, you might as well brew beer. LOL.)

Culturally San Diego is kind of a suburban wasteland--that means very little "Social Network Foo Yahooglezonsoft(tm) Buyout Bait". The "cool kids" are going to want to be in NYC, SF, or Austin with possibilities in LA or Chicago.

<comment><USER26> Kind of sad given that it's a pretty nice, clean place with some fun stuff to do downtown. Maybe it's a lack of vision given that it's a bit more, as stated, on the conservative, suburban side. The company I work for is helping redesign some office space just outside of town. The "branding" efforts are trying to tout it as a tech-friendly building with stereotypical signposts - yoga, cycling, etc. At the end of the day, it's a suburban office campus, with little to no good access to public transit, and not near anything walkable when you want to get outside the buildings.

I don't know if anyone has studied the benefits of this but I have to say it's so nice to just be able to walk out the door of the office at lunch and wander around, sit on a bench, etc. Escape for 45 min - 1 hr and be refreshed. I think that's the appeal in more 'happening' city areas, even if we don't acknowledge or necessarily know it consciously.

</comment></comment></comment><comment><USER27> I love where I live (CO) and, factoring in the cost of living difference despite higher market salaries, moving to SF would be a significant pay cut-- and I'm far from the only one.

</comment><comment><USER28> People have different lifestyles and they should choose where they move according to that. Lots of people move to SF from smaller cities and expect to continue living a suburban life.

</comment><comment><USER8> I got out of Seattle 25 years ago when I saw the writing on the wall. I don't regret it. SF has always been worse in terms of cost, density, self- importance, etc.

</comment><comment><USER29> SF or The City please -- never call it "San Fran"

<comment><USER30> The City is way too generic of a name. Bay Area people would only recognize this as SF--here in O.C., "The City" means Los Angeles. In NY, "The City" means NYC, so on and so on.

<comment><USER31> ...and most of the world would assume the City of London (the Square Mile, as opposed to Metropolitan London).

<comment><USER30> ...No, the point is the most of the world would assume "The City" to be whatever major city they are closest to.</comment></comment></comment></comment>


Wawa data breach affects millions of debit/credit card transactions - <AUTHOR> https://www.inquirer.com/business/wawa-data-breach-credit-debit-card-numbers-exposed-20191219.html <comment><AUTHOR> [https://www.wawa.com/alerts/data-security](https://www.wawa.com/alerts/data- security)

"Based on our investigation to date, this malware affected payment card information, including credit and debit card numbers, expiration dates, and cardholder names on payment cards used at potentially all Wawa in-store payment terminals and fuel dispensers beginning at different points in time after March 4, 2019 and ending on December 12, 2019."</comment>


Copying Is Not Theft - <AUTHOR> http://www.youtube.com/watch?v=H8JDEsfK6Qs

<comment><USER2> Despite all the blather, copying is just infringement. In order to make copying into theft, we'd really have to warp society. I personally think that making copying into theft would mean creating a privileged class of people, "rightsholders", analogous to the Nobility of feudal England or France.

Also, this little cartoon is really cool.

</comment><comment><USER3> This is the standard BS rationalizing. Copying is in fact theft.</comment>


Google Searches for Mergers Big and Small - <AUTHOR> http://www.eweek.com/article2/0,1759,2128730,00.asp?kc=EWRSS03119TX1K0000594 <comment><USER2> "Google buys a start-up once every few days, or around one a week"

</comment><comment><USER3> "It is better to partner with Dow Jones and the Financial Times...," Schmidt said. Blogger Arrington jumped in to add "...and TechCrunch."

Michael's always a business man.</comment>


The Life and Death of a Political Startup - <AUTHOR> http://poliana.com/

<comment><USER2> Interesting read and sounds like a noble effort. It's a bit of a pivot, but I would think there's a market for better tools for campaigns to target would-be donors. There's clearly demand for anything that is revenue-generating for a campaign, and while I'm not fully versed in your product, I think that smarter access to the data you were tracking could be useful there.

Most serious campaigns, even state level ones, have invested heavily in donor and supporter retention software. But fundraising outside of the painfully repetitive emails, still seems to follow what I found to be rather dated practices. I hosted a campaign event for a Congressional candidate (who ended up winning) and I was shocked at how manual the process was.

Heading into 2016, there sure will be no shortage of campaign dollars (and contracts) up for grabs.

<comment><AUTHOR> That's a great idea honestly. We hadn't really put in thought as to creating better tools for donors. Of course, this idea would only hold any weight if the donors are of substantial wealth. Being able to tell a donor "here's where to put your money based off of the district's political opinions or sway" would also be incredibly valuable, but is it enough to substantiate paying for a service?

I'd be more surprised if people with large amounts of money didn't already know where they were going to put their hard-earned cash. I'd be equally as surprised if those donors didn't already have connections of their own on the hill, at which point they wouldn't need our service for enlightenment (they'd have their own direct source).

I like the idea though, I would just worry about the ability to generate reliable revenue from this. Perhaps also the issue of ethics I wrote about would come into play here. It somewhat might follow the same path as we did when I talked about selling the data to politicians for use on their campaigns.

</comment></comment><comment><USER3> >Simply put, our primary goal was to avoid the very same bias that we felt the media had.

I'm not so sure that's what i'd want as a goal. I don't want to live in s a society where there isn't a bias against rape, murder, etc. You have to have biases but ensure they are well founded --based in some kind of set of principles. We don't need to start from the beginning and evolve our line of thought every time we discuss something.

I'm totally okay with someone saying I'm for increasing alcohol taxes because of reasons a, b and c which are based on peer reviewed and internationally accepted studies x y and z. So long as they are open to change were the conclusions to change over time (due to say new studies revealing something different.)

</comment><comment><USER4> Good post mortem, ironically most startups won't listen because startups by their very nature have "blinders" on.

<comment><AUTHOR> Thanks Quizz, I completely agree. From my experience that's a lesson that takes going through a few startups to finally break.

</comment></comment><comment><USER5> Simply genius.</comment>


Bug of the Year (2011) - <AUTHOR> http://antonym.org/2011/12/bug-of-the-year-2011.html <comment><USER2> Ah, just two processors without clock syncronization. Fast-forward 6 years and we have ways to explore memory that was cached for instructions that won't be executed, and leak the hell of the processors' hearts.

</comment><comment><USER3> This article pairs nicely with bcantrill's recently released talk "The Hurricane's Butterfly: Debugging Pathologically Performing Systems" [https://youtu.be/7AO4wz6gI3Q](https://youtu.be/7AO4wz6gI3Q)

</comment><comment> rwx</comment><comment> Here is the famous "500 miles email" bug

[http://web.mit.edu/jemorris/humor/500-miles](http://web.mit.edu/jemorris/humor/500-miles)

</comment><comment><USER4> It's always fun when you get to the bottom of one of these and find out some seemingly absurd mistake or design flaw, each layer peeled away reveals a new level of excitement. Even when it's not in hardware it opens up your eyes about the potential fallibility of all the layers beneath whatever you are doing.

<comment><USER5> And just about that time I notice the extra semicolon, delete it and recompile.

</comment></comment><comment> King-Aaron I was always a fan of OpenOffice's "won't print on Tuesdays" bug..

[http://beza1e1.tuxen.de/lore/print_on_tuesday.html](http://beza1e1.tuxen.de/lore/print_on_tuesday.html)

</comment><comment><USER6> Every time I think software is hard, I dabble in hardware for a bit.</comment>


A JS plug-in for web forms to allow in-line maths - <AUTHOR> https://github.com/gnehapk/CalcJS

<comment><USER2> Nice .. pretty handy</comment>


Ask HN: What language should I learn first? Any specific resources? - <AUTHOR> As a nontechnical founder, I'm looking to get into programming. At the current point in time, what's the best place to start?
I'd appreciate knowing what languages are best for what goals (and employability if needed), and any recommended online resources. Though I'm aiming for applicability as soon as possible, I'd also love any summaries of CS fundamentals, whether in the form of articles or more lengthy online courses. I want to learn it as best as I can.
Any personal anecdotes and tips would also be greatly appreciated!
Thanks in advance, HN :) <comment><USER2> In college, my programming classes were mostly in C++, Java, and C#. Those languages are generally important/important for working at companies like Google, Microsoft, Amazon, etc.

A vast number of jobs these days are looking for developers with experience working with web applications. Full-stack and front-end developers will almost always need to know JavaScript (mainly for client-side application development).

If you are hoping to just get your foot in the door and feel out if you enjoy programming or not, I would recommend starting with Python. It is widely used language that is easy to jump into and learn.

If you are hoping to learn programming via working on a small side project there are some great NodeJS courses/tutorials online. Personally, I've found some good courses of Udemy.com and some great tutorials at Thinkster.io.

Hope this helps!

</comment><comment><USER3> JavaScript, especially ES6. I also suggest a solid scripting language like Perl.

If you plan to go after "Enterprise" application development (which will actually be more like maintenance of legacy code), core Java is a good place to start. IMO it's easy to learn because it's so verbose but hard to be productive with for the same reason. Knowledge of Java can also get you into the world of Android app development.

If you want new and trendy, I would look into Ruby and Clojure.

And since everything is going to the cloud these days, definitely start looking into AWS.

</comment><comment><USER4> Python is a good chance for the non-professional programmer because it is easy to get started with, easy to hack things out with, but also solid enough that you can take something hackish and get it into production.</comment>


Nanomsg postmortem and other stories - <AUTHOR> http://sealedabstract.com/rants/nanomsg-postmortem-and-other-stories/ <comment><USER2> I personally traveled to Slovakia to meet with Martin, Mato and Pieter, a few years ago. I commissioned them to fix some annoyances I had with ZeroMQ.

I just want to say that they are all great people, they're very smart and have spent a lot of time deeply thinking about messaging.

I was really hoping to use nanomsg at some point, so I'm a bit disappointed to see all this. Really hoping that someone (Drew?) releases a new BSD licensed library.

</comment><comment><USER3> Yeah I dunno, the "solid technical reasons" are pretty unconvincing. The reasons are:

1\. Exceptions are awkward because they separate the error handling from the context that is usually required to correctly handle an error (i.e. where it occured).

2\. Exceptions are the only reasonable way for a constructor to fail. You can't return error codes from a constructor.

I actually agree with the point about exceptions, and I'm glad Rust didn't use them. That said, the solution is trivial (and the author admits it) - don't use exceptions.

The second point is also actually a fairly good one, and again Rust has fixed this - it uses static `new()` initialisers that create object (or not, if they fail). Fortunately we can actually copy this method in C++. Here's an example for a network connection object:

        class Connection
    	{
    	public:
    		static boost::optional<Connection> connect(string host)
    		{
    			// Try to connect.
    			int connectionHandle = -1;
    			int rc = connect(host, &connectionHandle);

    			// If it fails return none.
    			if (rc < 0)
    				return boost::none;

    			// Otherwise return the new object.
    			return new Connection(connectionHandle);
    		}

    		void send();
    		void recv();
    		void etc();

    	private:
    		explicit Connection(int connectionHandle)
    		{
    			mHandle = connectionHandle;
    		}

    		int mHandle;
    	}

Unfortunately as far as I can see there is no Rust-like `result<>` type in Boost or the standard library yet, but it would be fairly easy to write your own.

It seems pretty crazy to give up C++ for these fixable flaws. Especially given how many unfixable flaws C has.

<comment><USER4> Your connect method can still throw std::bad_alloc.

<comment><USER3> You could easily catch that within the method though. But in general I think throwing an exception on memory allocation failure is much better than the alternative, which is - in practice - assuming it succeeds and segfaulting.

</comment></comment></comment><comment><USER5> Very interesting read: worth the time.

See also: [http://hintjens.com/blog:112](http://hintjens.com/blog:112)

</comment><comment><USER6> Projects have to drive unbelievers out to work. Well, partly. It does not matter if someone is just not believing in one specific aspect of the project and ignores it. That is fine. But when the group starts to fight over what to do instead and this agreement can't be reached, then a split is necessary to enable common work of the people left.

Of course that can't work when the project has no working governance, if the project has not even a clear goal. If a project is only defending against unbelievers without having a consensus of its own. And I think that is what he is mainly describing here, without me being sure that is fully intended.

</comment><comment><USER7> So, what is the spiritual successor of 0mq?

I think a lot of use cases that would have been covered by 0mq are now handled by more higher level abstractions like consensus protocols or more heavy weight message queues (which absolutely makes sense), but what would be a modern (i.e. maintained) alternative for the simple "pub-sub via TCP" use case of 0mq?

<comment><USER8> ZeroMQ is a community of projects that has grown and evolved significantly in the last years. It was never threatened by Nanomsg, which we saw as an interesting experiment, and potentially an engine for a pure C stack. We have pure Java, C#, C, and C++ stacks, and a new pure Go stack.

Above that, you will see many language bindings, especially PyZMQ and CZMQ, each with a large community on top. CZMQ provides things like actors and CurveZMQ authentication, and has wrappings in many languages. I'm writing a Node.js one at the moment, and did a Java one a few weeks ago.

Above that, we have Zyre, a clustering library that is somewhat like Nano's bus pattern, yet rather stronger. It was designed for flaky WiFi networks, and does not lose messages as long as a node reconnects within a reasonable time.

And above that, we have a message broker, Malamute, which does pub-sub and workload distribution.

All the C libraries have rich packaging (builds for every conceivable platform, and bindings in a growing number of languages), provided by zproject. So you can start a Malamute server (a CZMQ actor) from Python, or Node.js, trivially.

We have run Malamute on a $25 OpenWRT router. This stack is small, efficient, and very alive.

</comment></comment><comment><USER9> nanomsg was an interesting successor to the bloated/C++/LGPL zmq, but it succumbed to old ways that don't work anymore.

It's 2016 and you can't run an (intended) global-scale open source project by just being "code nerd in chief." If you can't run an open feedback-driven community _and_ if you can't be chief architect (also means communicating plans constantly, not just 'do whatever you want') _and_ if you don't possess technical and professional excellence (also means being responsible with security issues and timely resolving of user issues), then you don't actually have an "open source project," you have a private uploaded code repository other people can see publicly.

Gone are the days of 1995 when you could live on an island and upload your new code once per year and everybody would leave you alone and praise you in computing magazines for being a genius. Now you'll have 1,000 issues on GitHub and requests for public appearances and proposals for changes and important security flaws to fix and requests for extensive communication about current designs and upcoming features.

The whole "i'm going to do this all on my own, everybody else go away it's my code" doesn't work anymore. Those projects are now destined to fail on their own without open and scalable community leadership. The good projects "get it" and the old guard are toppling as we speak. In another two years, nobody will trust open source projects without a stated scalable community model and codified successorship plan.

<comment><USER10> 99.99% of open source project does not and cannot match these expectations and it is so out of touch with reality just to assume so. Most successful open source project (apart from the well known 0.1%) are run by 1-2 maintainers and contribution from the so called community amounts to a few percent of the total work at best - look at the contributors graph of popular github project.

Unless projects are able to bootstrap themselves into a business (wordpress) or are eventually supported by a commercial entity (llvm) they will be fireflies that shines for a short while until the creator/maintainer does a reality check and realise how much time and work he has put into this with nothing much in return eacept a mile long issue list on github, lots of unfriendly noise and arguments from the community and insane expectations from users like yourself.

<comment><USER9> _a mile long issue list on github,_

If you have enough users to have "too many issues to handle," then you're big enough that you need an official governance and contribution structure. You're also big enough where you'll have a pool of high quality contributors to promote to project-level-oversight status.

Nobody is saying "do all this work for free forever," but people _are_ saying: "You have too much work you're avoiding. Why refuse to let other people help?" Once you reach a million users this isn't your private software anymore, it belongs to the community and you need to step up and allow faster development than one person can handle alone.

<comment><USER10> > If you have enough users to have "too many issues to handle," then you're > big enough that you need an official governance and contribution structure

I'm sure e.g. Ruby on Rails and Bootstrap would like some pointers on how to setup "an official governance and contribution structure" to handle their the long issue and PR lists.

> Why refuse to let other people help?

Very few if any wants to use their free time to work through an issue list like that. Someone might do it once and write a blog post about it, but unless someone does it all the time it does not help much.

Open source might be perceived as a free commodity, but like a public toilet, no one likes to cleanup and especially for free. Likewise, help in the form of P.R.s doesn't much help either unless it is aligned with the overall vision of the project. It more often than not isn't.

</comment></comment></comment></comment><comment><USER11> What I don't really understand is what's fundamentally wrong with ZeroMQ to warrant such forks. The project has a large user base and is very established. What's unfixable about it?

It was pretty obvious to me that nanomsg had very little chance to thrive. For an outsider what's so radically different about _any_ ZeroMQ competitor?

<comment><USER12> The nanomsg documentation (linked from the article) lists a number of fundamental differences between it and ZeroMQ. Some of them are implementation details, but there are quite a few fundamental design/API changes that would be impossible to make in an existing library.

[http://nanomsg.org/documentation- zeromq.html](http://nanomsg.org/documentation-zeromq.html)

</comment></comment><comment><USER13> once again i see the "no matter what they tell you, it's a people problem" issue. very nice analysis of how to reach this conclusion from a very technical position.

</comment><comment><USER14> It seems like for side projects that don't have an active community, the only viable approach is to set expectations right up front that it's abandonware. That is, write it, release it, and walk away. No future implied, unless someone volunteers to turn it into a real project.

Example: this is what most researchers do - they don't maintain the code after the paper is published.

</comment><comment><USER15> This piece is excellent. The backstory on the zeromq and nanomsg projects is fascinating and generously detailed. The trick of reaching out to gather rejected contributors is good humanity and practically clever. The rule about monitoring contributor entrance and exit rates, I get.

But I'm struggling with the implemention of the rule.

 _In almost every case, it is better to merge even a bad patch than to turn away a contributor for the projects I already struggle to maintain. So I try to get the patches improved, but I merge them even when I can't. Even bad patches are better than none._

With all due respect to the OP and everyone who have poured blood, sweat, and tears on these projects and as maintainers of others, this point is hard to swallow. How bad of a patch is ok to let through? How complex? How much of a deviation from the original design? Is the contributor going to be around to fix regressions impacting other users? If the patch is complex and taking the software in a different direction, is it a good direction for existing users and will people get on board to do the work to update the rest of the code? I think these questions are vitally important for maintainability, correctness, and performance of software in general. I would guess hashing them out is a significant portion of the actual work in open source projects and are why people fight on mailing lists and say no to patches in the first place. We fight because we care?

Working out the answers to these questions is so, so much work, and people just want their patches taken and maintainers just want to get on with their lives, so taking anything that comes along as a means of keeping the project moving may be the only hope in some cases. But I find it hard to believe it doesn't backfire more often, on grounds of user support and principles of software maintainability.

To name a couple projects that have had some success with different approaches, I've noticed the Clojure project seems to maintain a vibrant contributor rate while also exercising strict design control from the top. Project leadership takes heat for rejecting, in particular, feature requests, but from what I've seen they will work with you if you will take the time to work out your design in a way that fits the language and the maintainers' vision.

Secondly, the Waf maintainer strictly will not merge patches that change APIs, break anything for users, or do much of anything wonky internally, but from what I've seen he will work with anyone introduces new functionality that doesn't break old code and is in line with his view of the project. He worked with me to whip a shoddy patch into shape. I was grateful he bothered at all, and it would have been disastrous if he'd just merged it. Somehow he walks the balance of rejecting bad patches and protecting users while also merging quite a few hit-and-run contributions. The maturity of the project and decoupled architecture finely honed for the problem space may help support this style of maintenance.

So at least in those two cases the answer lies in a very skilled balance of engineering and social concerns, but not necessarily any patch is better than none.

<comment><USER15> ZeroMQ's Collective Code Construction Contract [1] goes into a lot of my question areas in concrete detail. It puts fair burden on both contributors and maintainers and clearly delineates the roles. Relevant to my post is the focus on identified and agreed problems and the requirements that contributors use the issue tracker and work to consensus on the validity of their observations and solution.

[1] [http://rfc.zeromq.org/spec:22](http://rfc.zeromq.org/spec:22)

</comment></comment><comment><USER16> So where does Crossroads fit in all this?

<comment><USER17> Crossroads was Sustrik's first attempt, after ZeroMQ, which he then abandoned (or renamed?) to start Nanomsg.

</comment></comment><comment><USER18> I wanted to use nanomsg 6 months ago. Google alone, at the time, had it as a better zmq. I had to _really_ read between the lines at the time to figure that it was losing momentum. It was not an easy sense.

I'm glad this forthright piece puts nanomsg incontrovertibly to pasture. It's thanks to clear pieces like this that people are able to navigate the open source world and choose technologies which, if they may not be theoretically the best, have the much more important characteristic that they are long lived, alive.</comment>


The most interesting logs in the world - <AUTHOR> http://www.johndcook.com/blog/2012/11/15/logarithms/

<comment><USER2> Pretty basic notation problem that was solved in my undergrad math program by writing ln (pronounced "lawn") instead of log to denote natural log.

All the math I do now uses lg, so I didn't realize the ln convention isn't common.

<comment><USER3> It's common everywhere except in ivory towers. Mathematical journals (english ones, at least) and the like use log to mean the natural log, because there's no need to use log_10 in any advanced/abstract system. (This is because 10 stops being a number of any import past being able to do arithmetic in your head; 10 is only special because we have that many fingers.)

The sciences have a definite use for log_10, since the metric system is based around powers of 10. A mathematician might argue that e.g. a log-lin graph would be just as useful with log_e as log_10, but then you lose the nice demarcations. It all depends who you're talking to and how they're using it.

As a professional mathematician, the author sees little need for log to mean anything other than the natural log. As a professional educator, I disagree. Clearly his readers are confused by the ambiguity of "log". He has a few options: do nothing and accept that inexperienced but curious mathematicians will be confused, use "ln" in place of "log" when writing wider interest instead of journal articles, or write a blog post complaining about it and hope the world will change to suit him.

edit: Although we pronounced ln "len" or "lin" instead of "lawn"

<comment><USER4> Ln-lin is the same as log-lin, since the only difference is a scaling constant, which is fixed by adjusting the position of the lines by the same scaling factor.

</comment></comment></comment><comment><USER5> Please see this follow-up post: Approximation relating lg, ln, and log10

[http://www.johndcook.com/blog/2012/11/24/approximation- relat...](http://www.johndcook.com/blog/2012/11/24/approximation-relating-lg- ln-and-log/)

<comment><USER4> Nice! Useless but fun example: ln 125 is approximately lg 125 - log 125 ~= lg 128 - log 100 = 7 - 2 = 5. Exact answer is close to 4.83, less than 5% error without ever thinking about a fractional value root or log.</comment></comment>


Ask HN: How much would it cost to sell yourself out to a company like Palantir? - <AUTHOR> <comment><AUTHOR> Palantir called me yesterday for a pretty senior position. I politely told them that they would need to pay me $500k just to talk to them, and they said they could probably make a $750k/year package.

I responded by sending the recruiter some doctored emails of Peter Thiel having sexual relations with a pig, and a copy of our constitution. He never responded, I don't know if I'm going to get the job.

Anyways, it makes me wonder. I used to believe that the people I worked with were generally ethically good people who stayed true to their own values, whatever they are. I told a friend of mine about this story, and he asked if I could refer him in, an that $200k was his sell-out number.

Personally a long series of tragedies in my life ensured I just don't give a $@$!$@! about money, and I have zero sell-out number.

What about you. Would you work for Palantir or an equally despicable company?

<comment><USER2> I would work for Palantir for about 100k and no other abnormal terms. Sorry to burst your bubble. It's a cold world out there and I've bills to pay and dreams to finance.

<comment><AUTHOR> :( I'm sorry to hear that. Have you considered getting a job as a developer? I hit $100k just before my 19th birthday and have never been below it since (I'm almost double now), nor had problems finding work.</comment></comment></comment>


The Myth of Income Stagnation, Again - <AUTHOR> http://blog.yardeni.com/2019/10/the-myth-of-income-stagnation-again.html <comment><USER2> Manifestation of inequality is often not even income decline but the fact that everything else has risen in price chipping away at your income.</comment>


NPM Security Insights API - <AUTHOR> https://blog.npmjs.org/post/188234999089/new-security-insights-api-sneak-peek <comment><USER2> They are revealing to the public if a package maintainer used Tor or 2FA. I do not think that information should be made public.</comment>


Why did Intel kill off their modem program? - <AUTHOR> https://semiaccurate.com/2019/04/18/why-did-intel-kill-of-their-modem-program/ <comment><USER2> Yeah, now that I think of it, Intel did lay off those "we are the leader in 5G" ads that I saw on all the tech sites in 2018Q4.

From a business standpoint I feel like I understand, but from a technical viewpoint, why has Intel struggled so hard to make parts other than PC cpus?</comment>


PipeWire 0.3 – JACK compatibility layer with comparable performance to JACK2 - <AUTHOR> https://github.com/PipeWire/pipewire/blob/0.3.0/NEWS <comment><USER2> I tried getting it running and working two weeks ago and sometime today as well. I had some real problems getting it working. The compilation ran without a hitch, but getting jack, alsa or pulseaudio to work wasn't really possible. Wanted zo open bug reports and read the wiki on github but they moved it to the freedesktop gitlab, but didn't update the links. Also the pages are mostly out of date or without any relevant information, but plans.

Can't wait to get a seamless setup for it, but I guess 0.3 is still too early for early adopters...

</comment><comment><USER3> Jack, while incredibly powerful has been a huge hurdle for pro audio on Linux. I'm looking forward to Pipewire being the default audio interface. Hopefully it drives a revival of the Linux sound engineering community and new software projects. Specifically the lack of a user friendly loop/sample-based recording tool like Ableton Live is glaring.

<comment><USER4> Can you describe what some of your hurdles have been? Pipewire is probably not going to solve your issues as it's not a complete replacement for JACK [0] and uses the same API anyway. Realistically, if you're writing a new DAW, you're still going to want to use the JACK API. If your problems are driver-related, that definitely won't be solved by switching to a different audio daemon.

And for the record, the open source audio community is not dead. There is activity, but you have to know where to look.

[0]: [https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ...](https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#will- pipewire-ever-be-as-good-as-jack)

<comment><USER5> To be fair, as the original author of JACK and the lead author of one the main DAWs on Linux, we no longer encourage the use of JACK with Ardour.

JACK is an exceptional powerful tool (if I do say so myself) but it is overkill for the majority (maybe even the vast majority) of users. We try to encourage most Ardour users to use its builtin ALSA audio/MIDI I/O support rather than JACK these days.

<comment><USER6> Paul, first of all, let me thank you for the great software you're developed. As a long time JACK user, Can you point me to a more detailed write up on why it is overkill?

<comment><USER5> There's no such writeup.

But look - most people don't actually want to connect multiple applications together to make music. Most people don't actually want to move audio between applications at all. As we get more and more (reasonably) good plugins available on Linux, the "monolithic" approach - do it all inside one program (e.g. a DAW or something a bit like it) is easier for most people (no complex state management) and closer to their pre-existing mental models.

If you _do_ need/want to connect multiple applications together, then sure, JACK is great and better than more or less any other possible alternative for that purpose.

But most people don't want to do that, and increasingly do not need to either.

<comment><USER7> > do it all inside one program (e.g. a DAW or something a bit like it) is > easier for most people (no complex state management) and closer to their > pre-existing mental models.

This may be a generational thing. As someone who learned recording in traditional analogue studios, I find a modular approach using JACK to be much closer to my own mental model.

</comment></comment></comment></comment></comment></comment><comment><USER8> Starting Jack and then patching stuff together was never an issue to me. It's not any more complicated than your imagined use-case for it, aka "patch program A into progam B"

ALSA is horridly complex and it's complexity is related to Linuxy stuff, not to anything resembling the work your actual audio converters are doing nor the task of getting data in and out of them!

A new layer added on top of ALSA will not fix this.

Nothing will fix this until some AUDIO people, who are NOT Posix Linuxy People write a realtime audio subsystem to REPLACE ALSA.

This will not occur anytime soon, for several reasons.

Both the Bela.io system and Elk's "brand new audio OS from the ground up" (LOL) utilize Linux but bypass ALSA to achieve their low-latency rock-solid audio pipeline. (the CTAG interface that Heinrich Langer designed appears to be the first example I can find of this approach)

They use Xenomai realtime kernel extensions to Linux to essentially run the audio driver as a real-time thread and the buffers your program writes to/reads from, are the actual buffers that DMA is moving the audio data in and out of to the ADC and DAC.

End of the day, audio isn't a posix API, and should never be considered as such. Want an abstraction? fine, wrap a callback as an audio server lol...

I had a Tascam USB audio interface that always sounded THIN on Linux and I wondered why, until I saw that the ALSA channel mapping had automagically applied a surround sound map to my 8 channels of output, which implied two lovely high-pass filters running at 75hz because the system was quite sure that's what everyone does with 8 channels of output... this despite the fact that ALSA saw 4 different stereo "devices" as my hardware interface presented itself...

IF ONLY this were merely a universally understood /etc/alsa.conf or something file... oh no no no! Linux People have SAVED us from audio configuration! Go look in /opt/didntknowthisfolderexisted/.confy/map.conf or maybe somewhere else... Add x-windows and the lack of any GUI application corresponding 1-to-1 with the "handy obscure utility" it purports to configure and control, and you have a match made in heaven!

Linux is an awesome server OS. It's a crap audio OS, and this is due to extreme cleverness and a total lack of paying attention to how any other audio API's in the world work except OSS... OSS isn't even an audio API FFS! it's like a printer API... you might as well use CUPS to run your sound LOL

</comment><comment><USER9> Good news to see work being done on the Linux-audio 'bottleneck'. I miss the ease-of-use and options available on other platforms (I left behind).

<comment><USER5> Trust me, the device audio/MIDI APIs are not the bottleneck.

Things like JACK (which tend to draw complaints) don't exist on other platforms (except ... by running JACK there), so complaining about its complexities (not that you did, explicitly) isn't really fair since that is based on an apples-to-oranges comparison.

I would guess that the options you miss are the result of application and plugin developers (not) being willing to include Linux in their target platforms. As cool as PipeWire _might_ turn out to be, it isn't going to have much effect on those decisions.

Finally, lots of people seem to manage to forget how for years (decades, perhaps), high performance audio software on Windows required _new device drivers_ (ASIO) for your audio hardware, because the ones that came with Windows couldn't do the job. This has mostly changed now, but ASIO is still with us nevertheless.

<comment><USER10> I don't know whether the audio APIs are a bottleneck for programmers, but for me complexity of _configuring_ ALSA[1] is a massive bottleneck to expecting _average users_ to be able to do prosumer audio on Linux.

With ASIO on Windows, all the user need do is install the driver and then select the ASIO device in their application. On Linux, if something is wrong with your ALSA config, you need to break out the text editor and become an expert in ALSA architecture and configuration. I've seen enough lost souls in this situation asking questions on mailing lists that I am convinced it is a major problem.

As someone interested in deploying an end-user application to Linux, the fact that there is no plug-and-play "it just works" solution[2] for low-latency audio is a big problem.

[1] More specifically: resolving misconfiguration.

[2] By this I mean a solution that works by design, not by luck.

<comment><USER4> Pipewire is probably not going to make your ALSA configuration issues go away. It's built on top of ALSA just like everything else. What it might do is make it easier to have low-latency audio across multiple devices. And it may save you some of the hassle of having to configure JACK and LADISH.

Would you care to mention what your device and particular misconfiguration problem is? I can't guarantee I can help, and if it turns out the issue is due to drivers then there's not really anything a sound server like Pulse/JACK/Pipewire can do about it. You can't design around that, it literally is just bad luck that you happened to have a device that is badly supported.

<comment><USER10> Thanks for offering to help. I'm okay at the moment. I was referring to other users reporting issues that turn out to be ALSA configuration problems (e.g. on the PortAudio mailing list). Sidenote: the fact that someone needs to offer help is part of the issue that I'm pointing at. Once a driver is installed on Windows or Mac OS I've never heard of someone experiencing misconfiguration of the audio subsystem as a whole.

The main ALSA misconfiguration issue I've personally encountered were not related to the audio drivers per-se, but to codec mixer configuration. It was on RK3399 SBCs from FriendlyArm. In that case I had to read the codec data sheet to work out how to set all the ALSA mixer flags and parameters correctly to get audio routing to send a signal to the output jack.

<comment><USER4> I'm not sure what larger issue you're pointing at and I don't think it makes sense to chalk this up to anything else; no sound server can magically figure out how to read that data sheet either. A random userspace daemon (that is optional) is just not the right place to put a fix for that. The burden for a fix likely falls on your distro to ship the correct udev rules, but figuring out what those are for all variations of hardware that use that driver is another story. With that who knows, the Windows and Mac driver could actually be doing something strange by default that just happens to work for most users, but isn't worth replicating if someone writing udev rules decides they want to do the "right" thing. See where I'm going with this? It's not just a quick fix, and I don't even know if it's the right one. Some other distro somewhere might even have a different way to do it. If you're really interested to make progress on this, you'll have to ask your distro's audio maintainers.

<comment><USER10> I think you put it well by writing "Pipewire is probably not going to make your ALSA configuration issues go away."

I never claimed there was a quick fix, but I kinda hoped that Pipewire/Redhat have the leverage to fix whatever needs to be fixed in the ALSA API to make userspace audio a seamless experience.

My naive impression is that the ALSA driver model is "broken"[1] -- most likely because many parts that need to seamlessly work together are atomized into different subsystems with no one organisation held responsible. As you seem to be suggesting, correct operation appears to depend on correct configuration by either the distro and/or the end user.

There should be nothing to configure. The driver architecture should be structured such that it is not possible to ship a "working driver" that then requires individual distro maintainers to intervene for the user to experience "working audio". For example, if the mixer hardware needs to be configured for correct operation, that configuration should be part of the driver or kernel, not some auxiliary file that may or may not be correct in a given distro.

[1] where by "broken" I mean that it incapable of providing the kind of zero configuration plug and play experience that is available on Windows with ASIO, or with CoreAudio.

<comment><USER5> Ross, the main issue with ALSA these days is not the API at all. It's the cases where the people responsible for the code cannot get (easy) access to the information required to program whatever hardware mixer is present in the device.

This can be true for devices following the Intel HDA "specification" (which is still so loosely constructed when it comes to the mixer that it's barely a specification at all). It's also true for many of the USB interfaces out there - the audio/MIDI I/O part works flawlessly on Linux (thanks to iOS' "no driver" requirement), but there's no way to configure the hardware mixer. MOTU went with a web-based configuration process for some of their devices, which is truly lovely since it works on any device with a web browser. But companies like Focusrite (and many more) continue to refuse to openly provide the information required for the ALSA internals to control the hardware mixer on these devices. In some cases, they have been reverse engineered, but often only partially.

Note that the same limitation applies when using those devices on iOS: you cannot configure them fully, unless the manufacturer makes an iOS version of the "device control panel".

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Does this mean we'll finally see Zoom screen sharing with Wayland? Hope the Zoom team gets this resolved soon.

</comment><comment><USER12> Note this is developed by a Red Hat engineer, so this is an an open source IBM contribution to Linux.</comment>


The Fight for the Metaverse - <AUTHOR> https://medium.com/@sophiaedm/the-fight-for-the-metaverse-811aef87d16a

<comment><USER2> Maybe WebVR, Web Assemblies, procedurally generated, with a push-enabled (HTTP 2?) web running on top of a data/content-oriented network.</comment>


Berkeley Students Build Free, Public Platform for Sanctions Investigations - <AUTHOR> http://sanctionsexplorer.org <comment><USER2> A Medium article giving some context was published as well: medium.com/@archerimpact/sanctionsexplorer-democratizing-access-to-ofac- sanctions-data-d448bad5ce37

It's describing the use for sanctions and some of the issues that the current US Treasury sanctions tool has.</comment>


Ask HN: What's your favorite fact about technology? - <AUTHOR> <comment><USER2> There are only 66 years between Kitty Hawk and the Sea of Tranquility

reddit post of the same: [https://www.reddit.com/r/AskHistorians/comments/6t1580/there...](https://www.reddit.com/r/AskHistorians/comments/6t1580/there_are_only_66_years_between_kitty_hawk_and/)</comment>


How necessary are var, let, and const? - <AUTHOR> http://raganwald.com/2015/05/30/de-stijl.html <comment><USER2> I found this article's premises and findings rather pointless, and kept on wanting the author to instead verify the premise "are there actually valid uses of 'var' now that 'let' exists?" (I haven't found any yet, and I'd like to know if I'm wrong). But maybe I'm too much of a pragmatist rather than an academic, so I suppose it wasn't written for me.

<comment><USER3> Yes! Thank you. I agree the question is as you pose it -- why use `var`, ever?

<comment><USER4> "let", of course, is a retrofit to Javascript. So was "var". In the early days of Javascript, before "strict mode", few people declared anything and most variables had global scope.

It's really hard to get a declaration-free language right. Python was the biggest success to date.

<comment><USER5> Huh? `var` was not retrofitted. I distinctly remember it being there since I started learning JavaScript, like around '96\. It is true that a lot of people were slack about using it, but that's just laziness, not that it wasn't there.

</comment></comment></comment></comment><comment><USER6> const IS valuable and necessary.

1) It means that every place the const appears it can be replaced with the const's value. Type checking can be streamlined, less indirection.

2) It communicates the developer's INTENT in an enforced manner. No later code change can accidentally make the const suddenly non-const.

3) const + deep Object.freeze() makes for a complete const.

Sure a human could hypothetically scan the code to see that the value has not been reassigned. This falls apart in practice. As soon as the company has a few dozen developers the code is constantly changing and such manual analysis would have to be constantly done.

<comment><USER7> 1.) is simply wrong. Const variables have a live-range hole where access to the variable either throws or returns undefined, depending on the language mode (and the VM!). In either case it _not_ legal to just smash in the constant.

2.) That's nice but JS semantics do not actually hold up. The intent is for a constant, the reality is there is a small window where the wrong results can be observed. Engines don't actually do any more optimizations than for var or let; in fact, your code may actually be slower due to the live-range hole checks.

<comment><USER6> So you are saying that there are race conditions currently? Are any of this race conditions actually required by the language spec? If not, I suspect that those race conditions will be eliminated.

<comment> david-given I believe that what the parent meant was that this:

function f() { console.log(a); const a = 1; console.log(a); }

...actually returns this:

undefined 1

So you get partially compile-time semantics (you can't assign to a) but partially run-time semantics (a only gets its value when initialised). Simply propagating the value of a's initialiser to all places where the variable is used is wrong, as this behaviour's required by the spec.

<comment><USER8> Actually that code example should throw an exception when the first `a` is evaluated.

<comment><USER9> It doesn't in v8 -- what do you mean by `should`?

<comment><USER10> It's an implementation error. In Firefox, it correctly throws:

> ReferenceError: can't access lexical declaration `a' before initialization

<comment><USER7> No, legacy const is not spec'd by ES5. It behaves differently in FireFox and V8 because it was added at different times with different semantics in the live range hole case. In strict mode, it will throw on V8 as well.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Hmm, posts like this make me want to make Lisp mandatory for all programmers. Given that LISPers have argued for "lambda the ultimate kitchen utensil/sinks/cooks" for the last few decades, it's slightly annoying that people from other languages repeat the point now. That said, congratulation for learning value of syntactical sugar. I hope you like it.

That said, can somebody implement hygienic macros in JavaScript. They will probably help will people having to explain basics knowledge over and over.

<comment><USER12> > Given that LISPers have argued for "lambda the ultimate kitchen > utensil/sinks/cooks" for the last few decades, it's slightly annoying that > people from other languages repeat the point now.

Why? Are you also annoyed by calculus students who learn ideas today that have been known for hundreds of years?

> That said, congratulation for learning value of syntactical sugar. I hope > you like it.

Maybe I am misreading this (it could mean simply what it literally says), but I read it as unconstructive snark.

<comment><USER13> I suspect that if mathematicians who were creating alternate number systems without calculus were continually learning the usefulness of calculus and telling the world, then yes, those who advised its inclusion for years would be annoyed, if only because it took so damn long and so much time was wasted.

<comment><USER12> Assuming that one is a fan of the sort of abstract computer-scientific approach to programming embodied by Lisp (and I am!), then it should be a _good_ thing when people discover it.

Is there a benefit in spreading this discovery to others, even after it's been known so long? Certainly I think so; it's new to everyone at some point, and, since I wasn't originally motivated to read McCarthy's original papers, I wouldn't have discovered the ideas of Lisp without recent expositions of it. Granting the benefit of this, who can better communicate with the unenlightened, in terms familiar to them, than a recent convert? (Although, as braythwayt points out ([https://news.ycombinator.com/item?id=9641279](https://news.ycombinator.com/item?id=9641279)), he is scarcely a newcomer to the party.)

</comment></comment></comment></comment><comment><USER14> Interesting and well written; if it were me, I might only change the ending a bit:

"Whereas, const […]. _It is not nearly as useful as immutable data, because the problem it solves is easy, not hard._ "

To something like:

"const may be more useful than adding something like immutable data to an imperative language with mutability deep in its DNA might be because it helps with one of the hardest problems; long-term, _correct_ re-reading by humans doing maintenance or extension."

But, the OP covers that well earlier in, so I'm not sure a third take on it would add much. Thanks for doing the exploration!

</comment><comment><USER3> Can you eliminate `var` by introducing an unnecessary function, declaring the `var`s as parameters, and then invoking? Yes you can.

Why you would ever do that, however...

<comment><USER15> This was my thoughts exactly. I stopped reading after that section. I don't understand what the author is trying to do.

</comment></comment><comment><USER16> const can be used to denote that a reference to the variable is being passed around and should not change for the lifetime of a scope.

        function f() {
          const queue = [];
          consumer(queue);
          return queue;
        }

It could be important to note that removing const has benign effect, but that it is there to ensure a programmer does not change the value of queue between `consumer(queue)` and `return queue`. Easily reasoned about, but extra safeguards from introducing bugs is always nice.

<comment><USER17> Ironically enough, but your example shows where const is shouldn't be used as guarantee of immutability: [https://t.co/JIQozGe7Md](https://t.co/JIQozGe7Md)

<comment><USER18> Isn't that a typical "corner case" in the understanding of dynamic languages bindings ? I think I've seen the same question pop about python. The array binding is constant, its content isn't.

<comment><USER17> if value of constant can be changed, it's not constant. In my understanding. And by Wikipedia: [http://en.wikipedia.org/wiki/Constant_(computer_programming)](http://en.wikipedia.org/wiki/Constant_\(computer_programming\))

<comment><USER18> That's typical computer lingo / semantic issue. the `const` mean shallow/pointer constant, not deep/structurally constant.

</comment></comment></comment></comment></comment><comment><USER19> If we use the approach of converting var's to named parameters, we also have to give up on passing variable numbers of arguments to functions. That is, unless we do something silly like:

        function silly(x, y, z, args) {
          args = Array.prototype.slice.call(arguments);
          args.shift();
          args.shift();
          args.shift();
          args.shift();
          x = y = z = undefined;

          // regular function goes here
        }

<comment><USER20> The replacement of var or let was a thought experiment to show the actual value--in code--of using them.

</comment></comment><comment><USER21> Does anyone else out there think Javascript `const` should really be called `final`? It more closely mimics Java's `final` keyword by preventing reassignment ("rebinding") of the variable, whereas `const` makes me think of full immutability as in C++.

</comment><comment><USER22> OK, I'll bite: what does De Stijl ([http://en.wikipedia.org/wiki/De_Stijl](http://en.wikipedia.org/wiki/De_Stijl)) have to do with any of this?

<comment><USER23> It was a movement that attempted to achieve clarity and elegance by omitting the unnecessary -- and the article discusses whether omitting formally- unnecessary features like _var_ or _const_ makes for more clarity and elegance, or less.

(Having said which, I notice that there's a reply from the person who actually wrote the article, and it doesn't say that. But that's why he _should_ have made the reference :-).)

<comment><USER24> I might have said that, but then I would be omitting the fact that not everyone finds my reproduction of the red-=blue chair comfortable.

Scheme vs. Common Lisp, and all that.

</comment></comment></comment><comment><USER20> To be fair; getting the benefit of const _would_ require code too though:

      function constUseful () {
        var guarded = 1;

        (function loop (orgGuarded) {
          setTimeout(function () {
            if (guarded !== orgGuarded) {
              throw 'guarded reassigned!';
            }
            loop(orgGuarded);
          }, 0);
        })(guarded);

        guarded = 2;
      }

      constUseful();

That's an approximation of const's value as delineated in code.

</comment><comment><USER25> A better question is how useful is _let_ at all? Having two different variable scoping rules with no way to know which one a variable is using without backtracing sounds like a maintenance nightmare. I understand what is it good for, but it seems like we are replacing a small problem with a bigger problem.

An even better question is why not get rid of _var_ and make every variable local to its parent function? To alter globals, use the window object explicitly.

<comment><USER26> > To alter globals, use the window object explicitly.

JS is used in non-DOM contexts as well. Though, of course, if that big a change is being made, a generic substitute for `window` could also be specified.

<comment><USER27> > a generic substitute for `window` could also be specified

Isn't that just |this| at the top level?

<comment><USER28> Not necessarily the _top_ level if you are referring to scope. `this` will be the default global unless another context is defined, whether you are at the top level or inside a function.

In node, there is a name for the default global: "global", which is also the default context. So node gives it a "generic substitute" as the OP suggested. Most people use "this" to make assignments to it, rather than the "global" name, since it is usually accessed from the default context.

</comment></comment></comment></comment><comment><USER29> Could anyone please explain to me why the author chose those functions for his examples? I got as far as callFirst() and repeat() and found it hard enough to wrap my mind around the functional / meta programming within. Are those actually good examples? It seems like there are simpler ways to illustrate the point.

<comment><USER30> If you check out Javascript Allonge (linked on the page, web version is free) you'll find out. The author has written a lot about functional programming, combinators and so on in JS.

I think his point was simply that examining how to emulate let/var with closures, it shows you explicitly what is different/similar about them. He's not suggesting anyone use those transforms.

</comment></comment><comment><USER31> let is obviously needed(devs like lexical scoping) but I found the whole var + let in the same language thing a bit confusing. The temptation to introduce yet another strict mode(to forbid var,and a few other constructs) is strong on this one.

<comment><USER24> var vs. let in the same language is a consequence of designing the language by committee, requiring 100% backwards-compatibility, and forbidding the addition of new modes (which is a back-door way to introduce breaking changes, while requiring browser vendors to essentially support multiple versions).

<comment><USER32> That behaviour is not exclusive to standards committees. The government and private companies do it all the time.

<comment><USER33> "governments and private companies" certainly do not preclude committees. Quite to the contrary, in fact.

</comment></comment></comment></comment><comment><USER34> > You can see every single rebinding of a variable within the lexical scope of > the function,

I do not think that is true, a called function can side effect the caller environment via `arguments` if that is passed around.

<comment><USER24> My understanding is that arguments caller has been removed, and Function.prototype.caller is non-standard:

      > The obsolete `arguments.caller` property used to provide the
      > function that invoked the currently executing function. This
      > property has been removed and no longer works.

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

Can you provide an example of modifying a declared variable in a calling environment? I'm very interested!

<comment><USER34> I meant this:

        function sidEffecting(ary) {
          ary[0] = ary[2];
        }
        function bar(a,b,c) {
          c = 10
          sidEffecting(arguments);
          return a + b + c;
        }
        bar(1,1,1) // I expect 12, but is 21

I now realize this could actually be not allowed anymore in recent ES, I am not sure, but copy & paste in chrome console still prints 21.

</comment></comment></comment><comment><USER35> That disclaimer is a bit of a cop-out, given the subject matter..</comment>


Show HN: Digestable Ingredient Database - <AUTHOR> http://digestable.co

<comment><AUTHOR> Recently I've become frustrated with the ingredient labeling on packaged foods. The ingredient label is meant to empower consumers, but we eat strange chemicals every day without knowing their origin, function, or safety.

So I wrote Digestable, an ingredient and food additive database. My goal is to make the ingredient label accessible to everyone. Each food additive is explained in short, simple terms- no chemical formulas, and avoiding or explaining jargon.

In addition to the ingredients, I've started a blog series that explains some other aspects of food additives. (e.g. "What is an emulsifier?" "What's in a Red Bull?").

[http://digestable.co](http://digestable.co)

API: [http://digestable.co/api](http://digestable.co/api)

Let me know what you think!

<comment><USER2> Great job! Do you also plan to add common kitchen ingredients(they're also present in packaged food)? e.g., "Egg White". I'd love to contribute to this.

<comment><AUTHOR> It's definitely on the list, though that's a lot more far reaching. Each of these definitions is custom written- not just scraped from Wikipedia, so it's time consuming. I'd like to get some more traction from this to validate the idea before going much further down that path.</comment></comment></comment>


Building an Is It Down for People (Yeoman/Angular) - <AUTHOR> http://davidandsuzi.com/building-an-is-it-down-for-people/

<comment><USER2> Why did I expect something scanning obituaries when I clicked on this link? :|</comment>


XDP Hands-On Tutorial - <AUTHOR> https://github.com/xdp-project/xdp-tutorial <comment><USER2> On some NICs (e.g. Netronome), the eBPF code gets compiled to the native code of a core on the NIC and runs there before the kernel even sees the packet. How cool is that?

<comment><USER3> Wondering whether some Mellanox NICs also have xdp offload... At 2x100Gbps I'd at least like make it help reorder, coalesce packets with application-protocol knowledge.

Anyone seen XDP use cases other than DDOS protection and firewall-like stuff?

<comment><USER2> I have been thinking about it for kernel-bypass CPU-bypass packet capture: DMA them directly to a big-ass hugepages-mapped ring buffer, where unprivileged user processes can then pick off interesting ones.

I use onload now, from an isolated core, but freeing up that core would be better.

<comment><USER3> Mmmh. I've been looking at the 'affordable' big-memory (4-6TB) HPE confs for just this kind of 'snapshot to disk every bit from all 10GbE NICs for the previous 10 minutes' feature.</comment></comment></comment></comment>