NCTA Agrees Title II Virtuous Cycle Is Working - <AUTHOR> http://www.wetmachine.com/tales-of-the-sausage-factory/ncta-agrees-title-ii-virtuous-cycle-totally-working-or-pais-economics-v-the-actual-real-world/ <comment><USER2> I've always felt the real problem is the monopolies. Net Neutrality doesn't fix that--it's up to local governments to fix it.

In the early 2000's when my home town still had dial-up only, Comcast came into the town and offered to build out cable broadband. They would even throw in a $300k grant to the school district for new laptops. The only catch? They needed to be granted a monopoly on all the telephone poles in the town. The town agreed.

As circulated on HN recently, the town of Chattanooga, TN is another interesting example[0]. Chattanooga made the smart decision many years ago not to grant a monopoly in exchange for a fiber build-out. Instead they built their own fiber network. Years later they offered to expand their ISP to the surrounding towns, which only had dial-up and satellite. It would cost zero taxpayer dollars. Instead the state decided to give $45 million to Comcast/AT&T to build out--get this--DSL!

As the parent article points out: despite cost-per-bit plummeting over the years, the cost to consumers isn't going down. The problem is monopolies naively being granted by local governments. In a world where that didn't happen, Pai would be right: ISPs would be forced to compete on features and quality, and so nobody would be talking about bundling websites like they do with cable channels, or whatever other nonsense Net Neutrality is designed to prevent.

[0] [https://motherboard.vice.com/en_us/article/tennessee- could-g...](https://motherboard.vice.com/en_us/article/tennessee-could-give- taxpayers-americas-fastest-internet-for-free-but-it-will-give-comcast-and- atandt-dollar45-million-instead)

<comment><USER3> I'm pessimistic about both arrangements.

I don't favor monopolies but, because I live in Los Angeles, I see that a city can act like a sluggish, greedy monopoly, too.

Here, the city owns the roads and electrical grid, and it's doing a mediocre or poor job of maintenance. We don't, for example, have "state of the art high throughput roads." Many of the roads are crumbling and need complete replacement. There's a huge backlog.

There's also a multi-year backlog of decaying wooden power poles which need to be replaced because they're in danger of coming down during a windstorm.

And, when people go to the expense of having solar panels installed on their homes, they have to wait many months for the city to come out and inspect and give permission to connect to the grid.

The city does not have a good handle on the problems. (Don't get me started about the leaky water mains.) City ownership of infrastructure is no guarantee of good service and value for money either.

And of course, as you say, with monopolies, we're screwed too. I don't see any easy answer.

<comment><USER2> All very good points, with great examples from where you live.

At the very least when decisions are made on a local level as opposed to state/federal, there is more of a chance that 1) people will be able to wrangle control of the situation by voting, and 2) the people who don't like the result can move away.

But you're right, it sounds like there is no easy answer for Los Angeles.

</comment></comment></comment><comment><USER4> One of the things Richard Thaler points out in _Misbehaving_ (on behavioral economics) is that traditional economics cannot decide whether out is descriptive or normative.

Descriptive economics would be the science of how people actually engage in economic activity. Normative economics describes how formally defined rational actors should behave to maximize their formally defined utility.

Unfortunately, what economists do is create a normative model and then retroactively assert that real people follow the model. As a result, their conclusions don't necessarily relate to the real world.

[https://www.bls.gov/opub/mlr/2016/book-review/behavioral- eco...](https://www.bls.gov/opub/mlr/2016/book-review/behavioral- economics.htm)

<comment><USER5> > One of the things Richard Thaler points out in Misbehaving (on behavioral > economics) is that traditional economics cannot decide whether out is > descriptive or normative.

That's because "traditional economics" doesn't actually exist as an entity, it's a strawman.

It can't "decide" because it includes different people amd groups who can decide, and who have decided differently.

<comment><USER4> " _Suppose the government its economy plunge into a deep recession and decides to give everyone a one-time tax cut of $1,000 per person. The consumption function tells us how much of the money will be spent and how much will be saved. Economic thinking about the consumption function changed quite dramatically between the mid-1930s and the mid-1950s._

" _[Keynes] assumed that if a household received some incremental income, it would consume a fixed proportion of that extra income.... If we take the case of a middle-class family that saves 5% of any additional income earned, Keynes predicts that the MPC from a $1000 windfall would be 95%, or $950._

" _[Milton Friedman] proposed that households would use a three year horizon to determine what their permanent income is, so would divide the extra spending evenly over the next three years. That means that in the first year, the family would spend about $317._

" _[Franco Modigliani] predicts that the windfall will be consumed evenly over [the remainder of the individual 's lifetime, say 40 years] meaning that the MPC to consume from the windfall will be just $25 per year._

" _[Robert Barro] assumes that their time horizon is effectively forever. In this world, the predictions about how much money will be spent depend on from where the money comes. If the windfall had come from a lucky night at the casino, Barro would make the same prediction as Modigliani about consumption. But if the windfall is a temporary tax cut, the beneficiary realizes that his heir 's taxes will eventually have to go up to pay for the cut he is receiving, so he won't spend any of it._

" _I gave a talk in the Cornell psychology department. I began my talk by sketching Modigliani 's life-cycle hypothesis. My description was straight- forward, but to judge from the audience reaction, you would have thought this theory of savings was hilarious. Fortunately, the economist Bob Frank was there. When the bedlam subsided, he assured everyone that I had not made anything up. The psychologists remained stunned in disbelief, wondering how their economics department colleagues could have such wacky views of human behavior._

p. 94-97

<comment><USER5> None of that is relevant to the ability of "traditional economics" to decide between being a descriptive and a normative field, as all are examples of hypothesized predictive models, not normative ones. They may seem naive from the perspective of a field focussed on behavior at a more micro level (even microeconomics aims at predicting higher-level aggregate behavior than psychology), and, heck, they may even _be_ hopelessly naive, but that's not even German e to the question.

(And whether or not an economist was there to put an imprimatur on it, _all_ of those descriptions are mischaracterizations, but again that's neither here nor there.)

</comment></comment></comment></comment><comment><USER6> Bulgaria is a good example why net neutrality works. The capital city of Sofia is brimming with ISPs -- last time I checked, at least 15 companies with good coverage, fiber, and very affordable ($7 to $20 for 100Mbps ingress and egress) connection services. And probably 50 or so more which are smaller and with less coverage, but still with strong connections.

No prioritized traffic. No metered traffic. No endless Facebook and Whatsapp traffic. Shielded and reinforced fiber-optic cables, laid underground. Rain pours down as if it's the Apocalypse, both of my connections never flinch.

It's different in the USA. It's vast, it's costly to make a big fiber-optic network, and the company lobbies and legal monopolies are rampant. I don't think you guys will manage to push back anytime soon. You need somebody like Elon Musk coming over and saying "I don't care about being in a VIP oligopoly club, I'll do my own thing". Then you'll find Comcast suddenly improving service and dropping prices.

People like Pai aren't stopped by words. There has to be a way for the market to do its magic, otherwise it'll only get worse for the USA.

<comment><USER7> >> _The capital city of Sofia is brimming with ISPs -- last time I checked, at least 15 companies with good coverage, fiber, and very affordable ($7 to $20 for 100Mbps ingress and egress) connection services._

Sounds like a domestic sector ripe for consolidation. I hope that doesn't happen for the sake of the consumers, but that seems like an overwhelmingly large number of players for a total market size of only 1.7M subscribers[1], which is even smaller from the census figures of roughly 500K households.

[1] [https://en.wikipedia.org/wiki/Sofia#Demographics](https://en.wikipedia.org/wiki/Sofia#Demographics)

<comment><USER6> Some of the bigger players have been buying smaller ones but in general the sector almost hasn't changed because the consumers switch away if somebody slacks a lot -- the tricks of "we're in a merge and you may experience some disruptions in the process" and a lot of other corporate lingo absolutely don't fly around here. People just smile and switch away.

The mobile operators also pushed a lot for consolidation several years ago but it seems they didn't have the leverage (and the money) to make it happen. Thank the gods for that.

So far it's all good, we're enjoying healthy competition and extremely good ISPs.</comment></comment></comment>


How Caffeine Evolved to Help Plants Survive and Help People Wake Up - <AUTHOR> http://www.nytimes.com/2014/09/04/science/how-caffeine-evolved-to-help-plants-survive-and-help-people-wake-up.html

<comment><USER2> One of the most successful adaptive strategies on earth right now is to be delicious and/or addictive to humans. It guarantees you'll get planted and tended at large scale. :-)

<comment><USER3> It's also caused the extinction of many things. I don't know if that's really the winning track.

<comment><USER4> >I don't know if that's really the winning track.

It is usually either evolutionary irrelevant or advantageous for one species to cause the extinction of another. It can help to eliminate resource competition or predators.

<comment><USER5> I think the fitness landscape is too complicated to justify that kind of assessment. Even with the non-universal qualifier "usually". I think a more correct statement would be to replace "usually" with "can be", and mention the possibility of it also being disadventageous or disasterous. At this point the entire statement becomes somewhat meaningless, though. Maybe it should just be "too complex to assess without a study per-ecosystem; it depends".

I'm sure someone more familiar with the research can express all of this mathematically and and confirm of deny the existance of an overall, cross- cutting model. It may even be common knowledge in evo bio/ecology/etc.

All I can mention on my phone right now is "keystone species", "s curve", and "wolf/rabbit populations". (or was it elk?) anyway, the latter search term leads to info on cyclical and highly dynamic ecologies. Check it out.

</comment></comment></comment></comment><comment><USER6> > When insects feed on caffeine-spiked nectar, they get a beneficial buzz: > they become much more likely to remember the scent of the flower.

This sound very interesting. But has it been reproduced experimentally? I would be very interested in seeing the results of such an experiment, as I'm not sure this would happen (at least not if the animals live in the wild).

<comment><USER7> Yes, just last year:

>We provide evidence that plant compounds pharmacologically alter pollinator behavior by enhancing their memory of reward. Honeybees rewarded with caffeine, which occurs naturally in nectar of Coffea and Citrus species, were three times as likely to remember a learned floral scent as were honeybees rewarded with sucrose alone.

[http://www.sciencemag.org/content/339/6124/1202.full](http://www.sciencemag.org/content/339/6124/1202.full)

<comment><USER6> Thanks for the reference! I can't access the article though, so I'll ask you: was this experiment conducted in the wild, or in a laboratory?

<comment><USER8> Trained bees, so laboratory. On the side, it's always worth googling the paper in question and poking around a bit. This is at the top of google result for the paper title: [http://phys.org/pdf287643238.pdf](http://phys.org/pdf287643238.pdf)

</comment></comment></comment></comment><comment><USER9> A better title would be "How Caffeine-producing Plants Evolved to Survive and Help People Wake Up". Caffeine itself is just a substance, it's hard to say it evolved by itself.

<comment><USER10> I'm not sure there's a meaningful distinction there. Caffeine is the (current) end product of an evolutionary process. If we went out and killed every caffeine-producing plant in existence today but continued to synthesize caffeine ourselves, caffeine would still be a product of evolution and would still exist, despite the fact that its "reproduction strategy" has changed from "biosynthesis by plants" to "industrial synthesis by humans", and that its continued existence is mediated by memes, not genes.</comment></comment>


Wharton Entrepreneurship Conference Tomorrow. 25 Cool Start-Ups. - <AUTHOR> http://wec2009.com/expo

<comment><AUTHOR> The Pizza Box One Is Awesome...

<comment><USER2> ...a bit unconventional</comment></comment>


HTML5 Google Authenticator - <AUTHOR> https://github.com/gbraad/html5-google-authenticator <comment><USER2> I were planning to make one. But then I found this. Afaik, many apps should be made using html. Btw. I would like to see TOTP mentioned instead of Google/Gauth. But I assume Google something is much cooler than anything else. See: [https://en.wikipedia.org/wiki/Time-based_One- time_Password_A...](https://en.wikipedia.org/wiki/Time-based_One- time_Password_Algorithm) \- So it's generic TOTP implementation, not Google(only) Authentication app trusting Google infrastructure. Also, there might be local storage security issues with HTML5 apps, but I'm not expert in that field.

<comment><USER3> Recently also Dropbox started to use the same TOTP implementation for securing with a two-factor auth. I have used the name G since they wrote the specification and at the time of this implementation, they were the only user.

I wrote the application so I would be able to use 2FA on my 'aging' MeeGo phone, the N9. No tools were available and implementing it with web technologies would allow me to port it easily to a desktop environment, an extension, etc.

</comment></comment><comment><USER4> I was wondering what I'd use this for (either as an end-user or as a developer), when I found that people actually use their google-account for two-factor authentication for their _SSH accounts_.

You know what? I don't trust Google enough to allow them to lock me out of my own systems, and I'm surprised other obviously technologically inclined people do.

<comment><USER5> Google Authenticator is just a client for the open OATH protocol. It doesn't rely on Google at all - there's no network connection, it's just a number being calculated from a seed + the current time.

<comment><USER6> Nitpicking: '... or a counter on the token/device'.

As far as I know Google Authenticator allows both time and counter based accounts. Not that it changes anything regarding the GP's misconception about accessing external services.

</comment></comment></comment><comment><USER7> So presumably it's compatible with any RFC 4226 / HOPT (<https://tools.ietf.org/html/rfc4226> <http://en.wikipedia.org/wiki/HOTP>) implementation?

<comment><USER3> Yes, and has been tested to work with Dropbox, Amazon, Dreamhost, Google, since they use different length of secrets.

</comment></comment><comment><USER8> At what point will we be dropping the '5' and just referring to it as 'HTML'?

<comment><USER9> Should follow Apple's lead and call the next spec The New HTML

<comment><USER10> Followed closely by:

The New HTML 1.1

</comment></comment></comment><comment><USER3> You can open it online from: <http://gauth.apps.gbraad.nl/>

Or install it as an application from: <https://build.phonegap.com/apps/135419/>

Chrome extension: [https://chrome.google.com/webstore/detail/ilgcnhelpchnceeipi...](https://chrome.google.com/webstore/detail/ilgcnhelpchnceeipipijaljkblbcobl?utm_source=chrome- ntp-icon)

And for those using FirefoxOS: <https://marketplace.mozilla.org/app/gauth- authenticator/>

</comment><comment><USER11> I've made a simple example hotp/totp implementation (<https://github.com/bjornua/totp.py/blob/master/totp.py>) in Python 3 for anyone interested.

</comment><comment><USER12> That's really cool for new mobile OSes. Time to "port" to Firefox OS ;)

</comment><comment><USER13> Great! This is a must-have app that I wasn't sure Firefox OS would have right away.</comment>


Ask HN: How low can Facebook stock go? - <AUTHOR> Does anyone see this anti-facebook wave putting the company into oblivion and wiping most of its value? <comment><USER2> It will never happen, the Facebook stocks decreased mostly because the NASDAQ decreased, about the issue with leaking of users data, nobody cares except HN

</comment><comment><USER3> I don't know if this is the market reacting to user engagement so much as the perception of potentially increased regulatory scrutiny. If USG was doing it's job properly, Facebook's ability to monetize would be dramatically lower than it has been historically. That's the real 'danger' right now from the investor POV.

</comment><comment><USER4> They'll be around for a while. They can lose half of all of their users and that would only reset them to like 2008 in terms of social networks--they'll still be the biggest. That's without counting Instagram and other user bases too.

<comment><AUTHOR> what if they post lower growth rates?

</comment></comment><comment><USER5> Facebook is only at July 2017 levels. So they're not really what I'd call "low," they're just regressed to a price point from less than a year earlier.

Only really impacts short term investors and speculators.

<comment><USER6> And even if the stock went super low with the information we have today by some miracle where every investor takes a stand and refuses to buy, stock doesn't impact a company's operations. A lower stock price doesn't mean a company makes less money, and "wiping out their valuation" only hurts investors.

A company's accountant couldn't care less what their stock price is (unless the accountant owns that company's stock).

</comment></comment><comment><USER7> It depends on FB engagement numbers. If they continue to rise, FB will rebound. If people really do stop using FB, hold on to your butts.my guess is that most people don't care though.

</comment><comment><USER8> No - most of their users (or "used" as is more accurate) are either oblivious or ultimately not caring.

</comment><comment><USER9> 0 is the lowest it can go...

</comment><comment><USER10> It's one of my fondest hopes right now.

I would pay for the privilege of seeing Mark Zuckerberg reduced to cleaning toilets and struggling to make his alimony and child support payments after Priscilla Chan dumps his broke ass and takes him to the cleaners, and indulging in the sweet, sweet schadenfreude.</comment>


Show HN: Covid Design Pack – Free set of Covid designs you can edit on the fly - <AUTHOR> http://www.artify.co/covid <comment><AUTHOR> Hello HN, I'm in in the beta stage of a new project: Artify, which is an online design editor, in the meantime, I wanted to collaborate someway with the current situation, by releasing these free pack of design and icons, that you can download and use in your projects and covid related campaigns. No attribution needed.</comment>


Ask YC: Data building - <AUTHOR>

We have recently completed one of the milestones for our web start up, and we are at the stage where we can start entering and building data.
Our idea is similar to TripAdvisor or Yelp, and we think we need to have a lot of data before officially launching our site, in order to attract  new users.
We were wondering what people usually do in this situation, because manually entering possibly thousands of items (and even fake users) is very time-consuming for two co-founders.
Thank you very much, and have a great day, all of you. <comment><USER2> Have you considered using Amazon's Mechanical Turk service?

</comment><comment><USER3> <http://freebase.com> would probably like to gather and hold your data. They have a nice GUI for editing it. People are starting to make other sites that use freebase, e.g. <http://www.dipity.com/>

</comment><comment><USER4> What about an outsourcing company like <http://www.b2kcorp.com>?

</comment><comment><USER5> For things that need to be manually entered take a look at Odesk and find someone who will do data entry cheap. I would probably never hire anyone for anything critical there and I wouldn't post my own services there but data entry is fine.

</comment><comment><USER6> What about scrapping data from similar sites?

</comment><comment><AUTHOR> Thank you all very much.</comment>


Seven steps towards becoming a professional developer - <AUTHOR> http://skilldrick.co.uk/2011/04/seven-steps-towards-becoming-a-professional-developer/

<comment><USER2> _And if you refactor without tests, "you're not refactoring; you're just changing shit"._

I'm reluctant to contradict this, because I am a fan of unit testing, but: it is entirely possible to safely refactor many programs that lacks unit tests by being disciplined about how you sequence the changes that you make. If you break down and organize your entire refactoring effort into a sequence of tranformations of your source code T1, T2,...Tn and you can prove to yourself that each step along the way that the behavior of your program did not change as a result of each step - and you can execute this sequence with fidelity, then you are refactoring, even in the absence of unit tests.

Although it is much better to have a regression suite.

Edit: on a more personal note, I remember when I first realized this. I was a young Java programmer, and I was given a class file and told to make it better. I had no idea what this code was supposed to do, and it was written by someone who was more of a project manager that wanted to try Java. It was enormous, and comprised of a mere handful of epic-ly long methods of deeply- nested if statements and loops. Everything was badly-named.

I was at a loss to make the code better without even understanding its function, but then my mathematical training kicked in: "...if I can make a sequence of small behavior-invariant transformations..." Aha!

<comment><USER3> I've definitely had moments where I threw together a pile of crap just to get a working product, and then went back later and used better naming, method extraction, more elegant error-checking, comments, sometimes a more obvious way of manipulating data, etc. No unit testing involved. Doesn't it still qualify as refactoring?</comment></comment>


The Inside Story On Why Kevin Rose Never Had A Big Hit - <AUTHOR> http://www.businessinsider.com/digg-kevin-rose-untold-history-2012-7?page=1

<comment><USER2> Sounds like he's already rich from his investments and he cashed out from investments in his own companies.

</comment><comment><USER3> The story of someone destined to be a successful investor rather than entrepreneur.</comment>


Three Different Ways to Create Objects in JavaScript - <AUTHOR> https://medium.com/better-programming/three-different-ways-to-create-objects-in-javascript-d3595d693296 <comment><USER2> Is there any way in JavaScript to create objects/functions with named variables?

Eg function(thisVar: 1, thatVar: 42)

I miss the instant readability of this so much coming from Swift.</comment>


France's military is training eagles to attack drones - <AUTHOR> https://www.washingtonpost.com/news/worldviews/wp/2017/02/21/terrorists-are-building-drones-france-is-destroying-them-with-eagles/ <comment><USER3> This is a copy-paste from what I posted on reddit in regards to the same kind of thing.

Really this entire concept is stupid. Not only are higher-end quadcopters unimaginably acrobatic, to the point where a skilled pilot could easily outfly a bird, but these things are literally flying lawnmowers. Go on /r/Multicopter or any other multirotor forum, there are loads of people that have been sliced all over their arms, and if you dig further, cuts down to the bone in some cases. Given the brittle, hollow nature of bird bones, well. (maybe eagle/falcon legs are different tho?) Seriously, if I was a falconer I would never consent to this. As for people suggesting they use cords or something to tangle the props up, that's really not an impossible problem either, people have been putting mesh cages over their props to fly them safely indoors for some time now, plus if you only stop one prop the quad becomes extremely violent in it's movements, pitching and rolling all over the damn place, which again, will probably at the very least hurt the bird quite a lot. Plus, if you were using quads for nefarious purposes, if that bird catches your quad you're not gonna give up and call it a day, more likely you'll push the throttle to max, which again, will cause that bird quite a lot of harm. If I were the aforementioned falconer, I would make sure the pilot cut the motors immediately before the eagle caught it, as that's the only way this would ever be safe for anyone involved.

<comment><USER4> I think a more fundamental problem is cost: Building one more explosive-drone is probably cheaper than raising and training one more bird, so an attacker would just send N+1 drones against N birds, and whichever drones detect interference can explode into shrapnel.

> Given the brittle, hollow nature of bird bones

Maybe they could make them little reinforced booties of kevlar and steel- sheathed talons? :P

Over in the realm of sci-fi, its interesting to contemplate bird-safe EMP grenades, or a neural-tap that makes the birds part of a spotter/targeting system for ground-based lasers.

<comment><USER5> They could also just use one of these[1] jamming devices to take down the drone.

[1][http://newatlas.com/battelles-dronedefender-beam-gun- uavs/39...](http://newatlas.com/battelles-dronedefender-beam-gun-uavs/39885/)

<comment><USER6> Then they just use what the military call an "anti radiation" method of target homing.

A crude suicidal drone with programming to 'avoid obstacles' \+ 'head to the source of the jamming signal' \+ 'blow up as near to the target as possible'.

Side note: "Anti Radiation Drone" sounds like some sort of scifi awesome sauce if you ask me.

<comment><USER7> The military already uses anti-radiation missiles with home-on-jam capabilities extensively.

Here's the US model, which will carry a 66kg HE warhead to 150 km: [https://en.wikipedia.org/wiki/AGM-88_HARM](https://en.wikipedia.org/wiki/AGM-88_HARM)

</comment></comment></comment></comment></comment><comment><USER8> Reuters photo for a visual effect of an intercept: [http://www.reuters.com/news/picture/photos-of-the- week?artic...](http://www.reuters.com/news/picture/photos-of-the- week?articleId=USRTSZ06O)

</comment><comment><USER9> >four eggs "were placed before birth on top of drones while still inside the eggshell and, after hatching, kept them there during their early feeding period

Why did they put the eggs on drones? Wouldn't that make the eagles think they are parents or related.

</comment><comment><USER5> Why not use autonomous drone swarms to attack enemy drones (any that does not respond with correct security certificate, for example) rather than a very costly solution, which while interesting and clever and lo tech, isn't viable in warfare scenarios.

<comment><USER10> Likely because falconers want funding just as much as drone builders.

But there might be more: having a heavy hunter-seeker drone over a crowd would be nearly as bad as having the occasional rogue drone there. Birds, with their amazingly low mechanical failure rate might be the preferable way of keeping reasonable people reasonable. Sensitive parts of the sky need to be kept clear of non-malicious, but nonetheless rogue drones not only because of accident risk, but also to get a clear threat indication from the malicious ones. "Probably just some kid who ran out of things to film with their gopro" is not very helpful when assessing the relative risks of a violent takedown over a crowd.

<comment><USER11> Based on the existing drone combat leagues - a lightweight drone with lots of streamers would do better than a heavyweight drone with any form of weaponry.

Foul the props, and the drone will go down.

Of course, I've also watched an expensive camera octocopter tip itself over and dive bomb the dirt because of a nearby antenna overpowering their delicate GPS.

</comment></comment></comment><comment><USER12> Consider for moment why the French are training eagles to take down drones: bombs. Now think about how the eagles are dealing with the drones... They knock them out of the sky. I can't be the only one seeing a problem with this.

"Use the 'interference gun'". If that works, and it's a BIG "if", the drone will either land or fall to the ground. Bombs away! Seriously, it's just as bad as an eagle crashing into it. Real gun? Same problem with the added bonus of a bullet going through the drone and continuing on its journey to who- knows-where.

So what's a government to do? The only solution I can see that removes the threat of a bomb going off is this: a much larger drone (650mm and above octocopter) armed with a net gun. The key here is to have the net tethered to the drone so it can carry the hostile drone away to a safe area. The drone- mounted net gun already exists (Excipio), just have to get the net tethered to the drone.

<comment><USER13> Bombs have an arming mechanism that triggers some time after they're released. They won't automatically explode just because they hit the ground.

<comment><USER14> A free falling drone bomb might. But more importantly: this isn't military grade munitions. This is home made acetone peroxide and the like I.e. highly unstable

</comment></comment></comment><comment><USER15> This approach is not all that new, but it's a clicky headline so it keeps coming back as news organizations cover it again and again. I remember seeing this over a year ago, and before that was well (in 2015 as I recall). A quick search shows a lot of coverage last year of Dutch police doing the same thing: [http://www.wired.co.uk/article/eagle-vs- drone](http://www.wired.co.uk/article/eagle-vs-drone)

<comment><USER16> They talk about that in the article.

> A solution presented itself in an experiment by Dutch police, who last year > used a trained eagle to pluck a DJI Phantom drone out of the air, Peter > Holley reported for The Washington Post.

</comment></comment><comment><USER17> Why not use drones to catch drones? The japanese, or more specifically, the tokyo police is doing that. Is that not really viable?

<comment><USER18> That sounds a lot more realistic but it's not as cool and romantic as eagles swooping in.

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

</comment></comment><comment><USER19> This is incredibly stupid. As I've posted elsewhere here, drones have a chance to outfly and outmaneuver the golden eagles used in the program. Then, assuming the eagles catch up, they still have to deal with blades - <USER2> wingtips spinning at hundreds of miles per hour. There's no way they can survive the blades: every bird I've seen that encounters a UAV either was instantly killed or permanently disabled. I've worked with drones enough to know what will and won't stop them. A bird won't: it'll brush the blades and fall to the ground in a bloody mess. A bullet will. Bullets are tried and true technology, we know how to use them, they're not ridiculously expensive, and they will certainly take down any drone of reasonable size.

This is PR, plain and simple. There's no other explanation for it, unless France's air force is hilariously incompetent, which I would doubt.

<comment><USER20> "The military is designing mittens of leather and Kevlar, an anti-blast material, to protect their talons"

Also, [https://www.youtube.com/watch?v=HifO- ebmE1s](https://www.youtube.com/watch?v=HifO-ebmE1s)

Maybe it won't work for all drones, but bullets would drop drones into the crowds below, so the idea catching them in the air is not that stupid. It's just one of the ideas the police is exploring.

<comment><USER19> If a bird catches a UAV, it's not going to be able to carry it off either. Golden eagles in particular cannot carry very much. You can find videos of them using their impressive wingspan to momentarily generate enough lift to carry dogs or goats, but that is only momentary. As you can see here [0], golden eagles can't even carry 1kg for more than a brief amount of time.

And you've got to be kidding me. "Mittens of leather and Kevlar"? How about you put on some leather-kevlar gloves and then try to touch a spinning blade, with the tips going hundreds of miles per hour. It would be like a heavy caliber bullet against a bulletproof vest.

This is PR, plain and simple. It's completely and totally ridiculous and wouldn't work unless the 'terrorists' were completely incompetent and flying tiny drones. (I'll remind you that a tiny drone can't carry much payload, which would probably be the purpose of a terrorist attack.)

Somewhere, entirely separate from the people working on this PR project, someone in the French military is hopefully looking at realistic ways to take down drones safely, e.x. bullets. But I can only hope that this isn't a serious effort and is only PR, otherwise I'd be extremely worried.

[0] [https://raptorresource.blogspot.nl/2015/11/how-much-can- bald...](https://raptorresource.blogspot.nl/2015/11/how-much-can-bald-eagle- carry.html)

</comment></comment></comment><comment><USER21> I think the reason that the French are investing in this solution is because other cheaper (or more effective) interceptor drone technology is still not ready to be used.

To think that the French army is not also investing on hunter drones is to severely underestimate the intelligence of that army.

</comment><comment><USER22> Magnets? EMP's? Is that still considered too sci-fi?

</comment><comment><USER23> What a scalable solution.

<comment><USER24> It is not meant to scale, it's a way to take down drones without shooting in crowded areas.

<comment><USER25> having high precision rifles with assisted aiming systems is surely way more effective.

<comment><USER24> Shooting guns in a crowded environment may cause panic.

<comment><USER26> May?

</comment></comment></comment></comment></comment><comment> sir-alien Got to wonder the damage that will happen to the bird. The larger drones which these tests are for would do some serious damage to the birds legs if the pilot kept the motors turning. If the pilot is intent on breaking away, they would not care about the birds well being.

Some of these drones also put out a fair amount of thrust so even if the drone is upside-down it could quite easily pull down the bird.

Somehow I feel that this training of large birds to catch drones just has not been thought through. Would a net cannon not but more successful especially when using high tensile netting. For mobility, attach net cannon to police multi rotor.

<comment><USER11> A multirotor carrying a heavy payload is not going to have a lot of thrust to spare to apply to the bird. The rotors only typically run in one direction as well, so it couldn't suddenly apply counter thrust.

Most multirotor autopilots also would behave in a very expected fashion when disturbed, making them pretty predictable.

</comment></comment><comment><USER27> Iron Beam is an already commercialized laser system, an alternative to Iron Dome missile defense against rockets and UAVs:

[https://www.wikiwand.com/en/Iron_Beam](https://www.wikiwand.com/en/Iron_Beam)

This sounds much better than eagles. One issue with eagles is that they have to be taken care of, fed, and deployed when needed.

This is like the old mechanization vs cavalry debate. Machines have many more benefits than just how they function at a specific task (ie, they dont get tired).

</comment><comment><USER28> Not going to work well, save for small drones capable of ridiculous payloads; a big one with more powerful engines and stronger props would seriously damage or kill the bird. To me the best way to neutralize a drone is by shooting it with a thin but strong steel net from another smaller and faster one: instant stop + faraday cage effect that probably also severs its connection with the launch base instantly.

</comment><comment><USER29> The article doesn't actually mention any examples of drones used by terrorists. The closest they get is a purely military action somewhere in Iraq.

</comment><comment><USER30> We had a related earlier discussion about ISIS terrorists using commercial drones as bombers. [https://news.ycombinator.com/item?id=13497150](https://news.ycombinator.com/item?id=13497150)

</comment><comment><USER31> This is not an unreasonable idea. I'm just going to leave this here. [https://www.youtube.com/watch?v=Hr- xBtVU4lg](https://www.youtube.com/watch?v=Hr-xBtVU4lg)

</comment><comment><USER32> You can't hack an Eagle!

</comment><comment><USER33> I am very sceptical about using eagles to stop drones. Eagles are more expensive to train and maintain, and they die.

The only viable solution against harmful drones are drones themselves.

<comment><USER34> The more I think about it, the more I think this is a bluf to push drone designers to overengineer their devices.

Eagles are not scalable, but it is way simpler to train a handful of them as a proof of concept than to eagle-proof existing designs of drones. And given physical and engineering limits, every countermeasure implemented in a drone will cut into the effective payload that is available for the drone to carry on its actual function.

The eagles were never meant to defeat the drones, but to force their designers to handicap those.

</comment></comment><comment><USER35> Alright, so they're getting leather gloves and are named after musketeers. How about equipping them with rapiers? Disable the drone blades with blades!

</comment><comment><USER36> In the movie _Legends of the Guardians_ the owls use steel over-talons to battle their enemies, that approach could be used here too.

<comment><USER37> From the article: "The military is designing mittens of leather and Kevlar, an anti-blast material, to protect their talons"

</comment></comment><comment><USER38> "on the other side of the world" \- half way down the article but omitted from the title.

</comment><comment><USER39> Another fact to consider here also is that eagles do not fly at night.

</comment><comment><USER40> Wouldn't it just be easier to shoot the drones down?

</comment><comment><USER41> That is a seriously large bird!

</comment><comment><USER42> Talk about animal abuse lol

</comment><comment><USER43> Read this months ago, why is this news?

</comment><comment><USER44> A simple automatic pneumatic injection gun delivering 2 laser-targeted shots of 30m distance, like this baby [http://www.haevic.co.za/index.php/products- services/the-dart...](http://www.haevic.co.za/index.php/products-services/the- dartdrone) can put eagle to a safe sleep, and ensure mission is not interrupted.

<comment><USER45> That did not go where I thought it would.

(I was expecting some kind of net gun for the drones.)

<comment><USER44> Well there are already deployed drones with tranquilizer dart guns that target humans. Used as "drone fencing" of sensitive areas. Example shooting from hexacopter: [https://www.youtube.com/watch?v=tNOL9Kz2WNE](https://www.youtube.com/watch?v=tNOL9Kz2WNE)

<comment><USER4> > Example shooting from hexacopter: > [https://www.youtube.com/watch?v=tNOL9Kz2WNE](https://www.youtube.com/watch?v=tNOL9Kz2WNE)

Uhm, that's not real or related. That's some guy's visual-effects project, and the drone is CGI.

Perhaps you meant the manufacturer's movie here? Good luck shooting a diving eagle. [https://www.youtube.com/watch?v=OItoIIoSefI](https://www.youtube.com/watch?v=OItoIIoSefI)

</comment></comment></comment></comment><comment><USER46> Wonder how this would fair on a predator drone firing hellfire missiles.

<comment><USER47> You mean the drones that are actually inflicting fear and terror on populations unlike the little camera drones the west is so afraid off.

<comment><USER46> Yep!</comment></comment></comment>


Clojure on the Google App Engine - <AUTHOR> http://www.fatvat.co.uk/2009/05/clojure-on-google-app-engine.html

<comment><USER2> There is one big limitation. The GAE doesn't allow you to spawn threads, which stops one big selling point of Clojure (concurrency).

<comment><USER3> Only _one_, you still get macros, robust data structures (for example hash- maps that take anything as a key), multimethods (dispatch on anything, not just type), lazy data structures, dynamic variables, metadata, etc. macros alone would be worth it in IMHO, the rest is just icing on the cake.

<comment><USER4> > multimethods (dispatch on anything, not just type)

Care to elaborate? I know Common Lisp's multimethods dispatch on class and object identity

      (defmethod foo ((obj class-name)) ..)

      (defmethod foo ((obj (eql object)) ..)

The first one dispatches if obj is of class "class-name", and the second dispatches if obj and object are EQL (i.e. strictly equal by value or pointer.) and this second one allows you to do very clean switch/case style dispatching on actual values.

How does clojure do it?

<comment><USER2> You can write a function that determines the dispatch action.

In the example below we dispatch my-add based on a function of the two arguments. This function returns a bool that determines the function to call, but it could return anything that you could then use to define the method upon (e.g. a symbol).

      (defmulti my-add (fn [x y] (and (string? x) (string? y))))

      (defmethod my-add true [x y]
        (str x y))

      (defmethod my-add false [x y]
        (+ x y))

      (my-add 3 4) ==> 7
      (my-add "3" "4") ==> "34"

<comment><USER4> I don't understand the need for defmulti.

      (defmethod my-add ((x integer) (y integer))
        (+ x y))

      (defmethod my-add ((x string) (y string))
        (concatenate 'string x y))

      CL-USER(8): (my-add 2 3)
      5
      CL-USER(9): (my-add "foo" "bar")
      "foobar"

Keep in mind you're dispatching on both arguments; the MY-ADD generic function is created for you and it's lurking in memory. You can add :before, :after and :around methods, which will allow you to get a hold of both arguments BEFORE the dispatch method is applied and after in a serial fashion, or AROUND the method dispatch altogether. This allows for stuff like logging, debugging, tracing, method wrapping and augmentation for moving-target type protocols and designs, etc.

<comment><USER3> No criticism of CLOS generic functions, but they accomplish something very different from Clojure multimethods. generic functions are intended to support objects. Clojure doesn't have objects, so Clojure does not limit multimethods to the kinds of use cases that generic methods are intended to solve.

Again you can dispatch on anything. Your dispatch function can return any value (a set, a hash-map, a vector, a list, a string, a number, etc.).

(defn new-dispatch [x y z] (meta y))

(defmulti my-multi new-dispatch)

(defmethod my-multi {:meta-key1 meta-val1} [x y z] ...)

(defmethod my-multi {:meta-key2 meta-val2} [x y z] ...)

This one dispatches on the metadata attached to the second argument.

</comment></comment></comment></comment></comment></comment><comment><USER5> For the interested, here's an example of using Clojure with Compojure on the GAE: [http://elhumidor.blogspot.com/2009/04/clojure-on-google- appe...](http://elhumidor.blogspot.com/2009/04/clojure-on-google- appengine.html)

</comment><comment><USER6> thanks for the post. I was waiting for this to be setup by someone. We also have php working on the app engine [http://www.webdigi.co.uk/blog/2009/run- php-on-the-google-app...](http://www.webdigi.co.uk/blog/2009/run-php-on-the- google-app-engine/)</comment>


Maybe We Should Stop Creating Inscrutable CLIs - <AUTHOR> https://www.philosophicalhacker.com/post/towards-readable-clis/ <comment><USER2> GNU utilities have addressed this problem for a long time. Maybe he's on OS X? You can install them there though. You don't need anything like PowerShell.

His

        cut -sf 2 -d \|

can be written

        cut --only-delimited --fields 2 --delimiter '|'

Likewise

        xargs -L 1 -I % jira attach rm %

can be rewritten

        xargs --max-lines=1 --replace=% -- jira attach rm %

These are options are easy to find with cut --help and xargs --help. Or 'man cut and 'man xargs'. (Though honestly it's weird that xargs doesn't accept --max-lines 1, only --max-lines=1 ? )

\---

I plan to add a mode to [http://www.oilshell.org/](http://www.oilshell.org/) to support longopts in all the builtins, e.g. instead of

        read -r -d ','

instead of

        read -raw -delimiter ','

I wrote a blog post last night that shows other benefits you can try now:

 _Oil 's Stricter Semantics Solve Real Problems_ [http://www.oilshell.org/blog/2019/08/16.html](http://www.oilshell.org/blog/2019/08/16.html)

<comment><USER3> In the article he talks about the longer flag names. But the commands themselves are inscrutable. 'xargs?' 'cut?' in neither case can you accurately infer from the name what it does. definitely a good pattern to just name things what they do.

<comment><USER4> That's only the case for an operator that is rarely used. Once it becomes a primitive of your language, a heavier name gets in the way. You've integrated its meaning now, so you no longer need it explained, but the cost of the extra length continues forever. This is why we don't write, say, "x multiply y". Given this tradeoff, I'd say xargs and cut are good names for those commands: rich enough to convey a large portion of what they do, but short enough to be wieldy and—critically for shells—not to take up too much of a line.

<comment><USER5> I think that argument made sense years ago when people thought completion systems were slow or bloated, but on modern computers anybody who still thinks that way is antiquated or weird. The defaults shells are shipped with are a problem of course, but that could/should be addressed by distro packagers IMHO.

Consider the long identifiers used in various modern lisp dialects for instance, particularly scheme dialects. It doesn't bother people because Emacs and vim both have completion systems.

A bigger issue with renaming all these utilities is it would negatively impact people who've already learned them. Alienating your existing userbase to appeal to newbies might be in-vogue these days, but I think it's crap.

<comment><USER6> Waiting for a completion system breaks the flow of thought, no matter how fast it is. After a certain point, they tend to start getting in the way.

<comment><USER5> Completion fast enough to be faster than a human's reaction time has been feasible for many years now. Furthermore there are completion systems that let you type discontiguous parts of your target word, essentially giving you the best of both worlds.

<comment><USER6> To truly be fast enough not to break the flow of thought->text, it has to (for me) be ~2 tokens ahead of where the cursor is, not completing the current one. And even then I doubt it'd work completely, because it requires rapid context switching to check the completion and pick the right one.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> This seems to be primarily an argument that "CLIs should support GNU-style double-dash options". I agree with that argument, and in most cases it's easy to add support for them. Most option-processing systems support double-dash (long option names), and I find them much easier to explain later.

The problem is that at least historically many of the _BSD developers, and thus the POSIX standards community, strongly resisted standardizing support for double-dash. So while utilities_ allowed* to have long option names, the POSIX standard doesn't directly support them and doesn't standardize them. That means that if you want to write _portable_ invocations of common tools, the only way that always works are the short (single-letter) names.

It may be time to revisit this decision. If the *BSD developers (and so on) are now willing to accept long names, and the POSIX standard is finally modified to support it, that would eliminate at least one roadblock to actually using them.

<comment><USER8> Every time I wind up doing

      > java -v

      > java --version

      > java -version

<comment><USER9> Don't forget -V (since some applications use -v for verbose)

<comment><USER8> This is java, it would be

-D-XX:VerboseRuntime=true

<comment><USER10> -XX is for implementation specific VM flags an generally uses + or -

-D is for system property and uses key value

so it would either be

-XX:+VerboseRuntime

or

-Djdk.runtime.verbose=true

</comment></comment></comment></comment></comment><comment><USER11> One thing the author's missing is a consideration of how often a system is used vs. how often it's learned. Let's just take one example from the article. Would it have been better if `sed` had been named `streamEditor` from the start?

sed was written in 1973. Think about that, it's been around for half a century. It's regularly used by millions across generations. Imagine how many countless man-hours have been saved from naming it "sed" instead of "streamEditor"? And I'm not just talking about typing code, but also reading code.

Yes "sed" is pretty inscrutable if you don't know Unix. But pretty much any Unix developer or sysadmin instantly recognized "sed" the same way they would a common English word. Very few people just use the Unix command line tools a few times, then forget about them. Once you learn Unix, chances are you'll keep using it for decades. And for those people, their brains almost certainly parse "sed" much faster than they would "streamEditor".

So, I think here's the lesson. The utility of terseness is very much related to the relative balance of expert users vs novice leaners. If you expect your system to mostly be repeat power-users, then terseness is very good. Systems that are around for decades, used widely by thousands, and general-purpose frameworks tend to fall in this category. In contrast, a high percentage of your user's man hours may just be people getting acquainted with the system. Maybe it's an application that solves some niche corner case, and most people use it once or twice then forget about it. Or maybe it's some internal software, where corporate turnover means that most devs working on it at any given time are neophytes. In this case verbosity and explicitness is a very good thing. You're not trying to cater to power-users. You want things to be as clear as possible, even if it means a lot of typing and spelling errors and wasted screen space.

The challenge here is that you mostly need to make these decisions at the development stage. You have to try to predict what your user-profile will look like, before you actually have any users. I doubt the original authors of sed could have ever imagined how popular and lost-lasting it would become. But given that it has, there's no doubt they made the right choices.

<comment><USER12> On another hand, imagine if the original computers on which unix commands were designed weren't restricted to 80 characters terminals with a few kilobytes of memory and almost no storage nor CPU. I'm pretty sure the author would have favored much more expressive commands.

I think design of those command lines were done first and foremost because the underlying system constraints were huge. Now that we have tabs autocomplete on shell and IDEs, the length of a command pretty much doesn't have any kind of importance.

<comment><USER13> > _I 'm pretty sure the author would have favored much more expressive > commands._

The very first compiled computer language was designed to be very expressive and able to be read almost as English, and be simple to read and understand. Would this be what you wanted? Would you change your mind when I tell you its name is COBOL?

<comment><USER14> > The very first compiled computer language was COBOL

FORTRAN and Lisp both predate COBOL.

<comment><USER13> Lisp was never compiled that early; that came much later.

But sure, I stand corrected; FORTRAN was technically the first compiled high- level language.

</comment></comment></comment></comment></comment><comment><USER15> That bash code he posted as 'unreadable' is perfectly clear to me, and I don't even know anything about the jira command line interface.

I think the real problem here is people always have preferred tools for jobs. The author obviously spends more time with JavaScript and finds that to be clearer and easier to write. I spend more time with bash and for me, it's very clear. It doesn't make it 'inscrutable'

<comment><USER16> You have to admit the bash code is less readable to someone who hasn't used those particular CLI arguments or flags in a while (or ever), as compared to someone trying to read the JavaScript version without knowing much about JS or the library that the code used.

You might argue that this is an acceptable trade-off to make to in order to gain terseness and ease of typing. But this is different than saying it's just matter of tool familiarity.

<comment><USER17> Yes, but how much less?

I find the bit of bootstrapping I need to make sense of shorter length operators and options pays off when writing and or reading later.

</comment></comment></comment><comment><USER18> (Arguably?) Powershell seems to take this approach. I have to admit, I like it philosophically, but whenever I try to use it there's some part of it that feels icky to me. It might just be microsoft's ConventionOfOverusingCapitalizationEverywhere though.

Here's an example of what powershell looks like:

        Install-Module DockerMsftProvider -Force
        Install-Package Docker -ProviderName DockerMsftProvider -Force
        (Install-WindowsFeature Containers).RestartNeeded
        Restart-Computer

IDK, it's undeniably easier to read than the Unix version. I have to admit some part of me just doesn't love how it looks though.

<comment><USER19> For a case like this, idiomatically I believe it'd end up as something like this in Powershell (though I've never seriously used Powershell):

      Get-JiraAttachment -Ticket {{args.ticket}} | Remove-JiraAttachment

… because Powershell pipes are structured, rather than just being strings.

If you were just wishing to emit the attachment IDs, you'd pipe the first bit through something like `Select Id`.

</comment></comment><comment><USER20> As other comments have pointed out, it seems like the author is looking for PowerShell. I have used a fair amount of PowerShell and it always leaves me feeling like I should just fire up Visual Studio and learn C#. I think that shell languages _should_ prioritize terseness at the expense of readability, allowing experienced users to accomplish their goals as quickly as possible. Any code that you expect others (or yourself) to maintain in the future does not belong in a shell script.

<comment><USER21> Couldn't disagree more.

 _Any code that you expect others (or yourself) to maintain in the future does not belong in a shell script._

Why? A shell script is often the best tool for the job. If your reason is that shell scripts aren't maintainable, then this is a circular argument basically amounting to "we shouldn't make shell scripts maintainable because we shouldn't ever maintain shell scripts because shell scripts aren't maintainable".

 _allowing experienced users to accomplish their goals as quickly as possible_

Having both short and long versions of each flag seems to give you the best of both worlds.

<comment><USER22> I agree that ideally shell scripts should be maintainable, and that designs which allow both succinctness and maintainability – like supporting both short and long flags – are preferable. But there will always be cases where you have to choose between the two, and in those cases I think a shell should choose succinctness. For all of the Unix shell's weaknesses as a programming language, it's an incredibly powerful tool for interactive programming, writing one-liners at the shell prompt. And when you're trying to program as close as possible to the speed of thought, every keystroke counts.

<comment><USER21> _And when you're trying to program as close as possible to the speed of thought, every keystroke counts._

And when is that ever important? I've been in development and sre roles for decades, and I've never been in a situation where I have to program at the _speed of thought_.

The only time I've seen milliseconds matter is watching movie depictions of hackers.

</comment></comment></comment></comment><comment> swagasaurus-rex People here in these comments are claiming that terseness in CLI commands is a good thing.

Perhaps there is a way to do one better? I could imagine an interactive shell that can show you the relevant portion of the man page for that specific flag.

Man pages never have sat right with me; I would love to have a shell that can show me (intellisense?) the most common flags and options commands are run with.

The command line is powerful but the barrier to entry is high. Anybody who does not fathom complexity hidden behind pages of manuals is doomed to be overwhelmed with the sheer ignorance and lack of discoverability a shell provides.

<comment><AUTHOR> >Perhaps there is a way to do one better? I could imagine an interactive shell that can show you the relevant portion of the man page for that specific flag.

I've had a similar idea before. I think this is a great way to think about the problem.

<comment><USER23> Just like so many other comments in this thread, you're describing powershell. There's autocomplete for parameter names in the basic powershell.exe prompt, but VS Code, VS, and PowerShell ISE (integrated script environment) all show argument types and docs through intellisense.

</comment></comment></comment><comment><USER24> I think Powershell tried to do something like this article suggests. I appreciate the efforts, but do agree with the common criticism of verbosity.

Also, it goes to show that no matter how bad aspects of bash are, the power accumulated over the years is hard to match, and a lot of that power is strongly coupled to the arcane and terse conventions.

<comment><USER25> Powershell is almost good, yet it falls off the mark in about a dozen ways.

A lot of very simple things are harder to do (text is easier than objects up until a point) since Powershell treats everything as objects and LinuxCLI/Bash does everything as text being piped around to specific commands.

The biggest complaint I have with Powershell is that it is so obnoxiously slow at parsing text files, that it just can't do basic scripting tasks on even medium sized files ~100MB without tons of StreamReader[] overhead or without calling a pre-compiled C# binary directly. This is the biggest fail. Nearly all the obvious ways of appending to files or parsing them stop working once the file size gets bigger than tiny. This isn't a problem with Linux commands that just pipe text to highly optimized C binaries. I'd drop Python for 90% of my scripting tasks on Windows if Powershell were faster in this area, but it is just painfully slow (if all the obvious ways of doing something in Powershell take ~5min when even Python can do it in ~4sec, you have a problem).

However, you can usually write some very beautiful and easy to read code by using the built-in objects once you learn them. I also like how powershell's functions allow you to create commands with parameters in a super easy way so you can easily build DSLs in a way. Everyone feels differently, but calling my commands in this manner (InvokeCommand -param1 "blah") reads a lot more naturally to me than (Object.Method(param1)). Also, Powershell can handle things like filesystem interaction in a way that doesn't feel like a bolted on afterthought as Python's does.

<comment><USER24> Thank you for the insight. I don't do a lot of powershell daily, but the last time I had a big batch job I was disappointed in how clunky it was to make a foreach-object -like pipeline utilize a sensible number of processes. I have forgotten the details but I think I needed some sort for add-on that split jobs across processes. Also, the pipeline wasn't _pipelined_ in the parallelism-sense.

<comment><USER25> No problem. I'm certainly not an expert, but that is mainly due to the deficiency I mention above. I'd use it for a lot more use cases if it could handle those scenarios.

I think Powershell "jobs" can help run things in parallel, but I've never done more than just read about it. The Powershell in Action book (3rd edition) covers that functionality I think. The first chapter to that book is pretty awesome.

My dream as someone forced to use Windows would be for Microsoft to use some dollars to make Powershell a one stop shop for data science, simple games (think commodore sprites), numerical computing...etc. That sounds a little wacky I know, but I think people would appreciate every computer shipping with a powerful environment like that. Since Powershell is built on .NET, surely someone could make a library for Powershell that abstracts away some of the .NET complexity to where I can just do something like:

Process-Data -data "blah.csv" | Create-PieChart -output "chart.png"

Not having to install Anaconda and import a ton of libraries on the target computer would be helpful. Note that I'm not saying to reproduce all of Matlab in Powershell, but putting some of the most popular routines as built-in commands would be pretty awesome.

<comment><USER26> I like the sound of your dream, but I don't think there's much commercial return on making a fun to play with 8-bit home computer environment. That's what Raspberry Pi wanted to be, and instead it became "cheap web browser host" and geek paperweight. The PS team is small, their real goal seem to be to encourage you to Azure through managing it with PS from any OS.

It would be up to "the community" to make modules to do this kind of thing, which would be possible if anyone wanted to, but unlikely to ship with Windows.

> putting some of the most popular routines as built-in commands would be > pretty awesome.

Microsoft's push is to avoid more "bloat" by leaning more heavily on optional modules installed from the PS Gallery. But `group-object` is a builtin for doing a kind of SQL GROUP BY operation, and Measure-Object just gained a -StandardDeviation option, and there's now ConvertTo/From-Json, and ConvertFrom-Markdown. If there is a basic routine that would be popular and fit many use-cases, you could request it at [https://github.com/powerShell/PowerShell/issues/](https://github.com/powerShell/PowerShell/issues/)

There is a GPL licensed scientific computing framework called Accord.NET, it's not wrapped for PS but can be used almost directly, and some of these others might be viable as well:

[http://accord-framework.net/](http://accord-framework.net/)

[https://www.reddit.com/r/PowerShell/comments/5ijcj7/kmeans_c...](https://www.reddit.com/r/PowerShell/comments/5ijcj7/kmeans_clustering_with_accord_framework_net/)

[https://en.wikipedia.org/wiki/List_of_numerical_libraries#.N...](https://en.wikipedia.org/wiki/List_of_numerical_libraries#.NET_Framework_languages_C.23.2C_F.23.2C_VB.NET_and_PowerShell)

<comment><USER25> Thanks for your thoughts. You're probably right about the pipe dream.

I agree that there isn't much commercial incentive, but I honestly don't see why major OS providers can't include some basic graphics primitives in the OS. I'm not talking about embedding the unreal engine or anything. It could be used for a lot more than primitive games btw.

I understand the desire to avoid more bloat. I can't believe Windows 10 requires the storage and RAM that it does.

The XML & JSON objects are pretty cool.

I'll check out Accord.NET framework too.

</comment></comment></comment></comment></comment></comment><comment><USER27> The problem is that the shell is frozen in time. have not evolved and it show.

The shell is just BAD. Anti-USERS and even anti-APPS!. composing commands in shell is just BAD. Is the worse API you can cobble in a hurry.

\--- I love the interactivity of it, but frankly FoxPro DOS 2.6 have a MUCH better experience. And in fact exist many others experiences of interactivity much better (Smalltalk, JS Dev tools, Jupyter notebooks, etc).

I have dreamed about this and think will be nice a shell that:

1\. Instead of just BLOB of binary-hopefully-is-text-maybe it interface with SHAPES and TYPES:

        enum Data {
            Stream(Data),
            Lines(Scalar), //utf8, bytes, ints, bools, etc...
            Table(Header, Data),
            Tree(BTreeMap(Data, Data)),
            Graph(Nodes< Data >)
        }

This abstract interface will support most stuff we need. Then with mime-types you can request "Tree as JSON" and get that.

This is similar to HTTP headers: But instead of html and that you ask for a shape and the type of it. Of course some utilities will only support some and can reject. And at minimum can return BLOB for interoperatibility with old shell utils.

When returning you get the mimetype/shape so will know that the blob is really a JPG and use that fact for displaying purposes and type inference.

With types and shapes you will get some static type validations.

2- Rich output (images, graphs, etc).

3- Uniform help and API discoverability alike swagger.

4- More rich and uniform API for the language that glue all.

For example is nuts that each utility must reimplement sorting, filtering, etc.

Instead if the shell have filter/map/group/etc in-built commands together with shapes and types:

        csv "sample.csv" filter: .. group: ..
        |> map:..
        |> zip "sample.zip"

ie: Is like a database interface

<comment><USER28> You mean using something like typescript as a shell language? That could work and it would leverage the javascript runtime and yet provide the rich type system and benefits.

<comment><USER27> I don't focus in the language itself but in how interface between utilities. The shell is a place for a light scripting layer and make talk apps in many langs.

Instead in what the utilities talk. Like in a REST interface you declare the kind of data (table, tree, lines of text, a binary blob) and this unlock what combinatory commands are available (so for table/lines you get relational commands for example) that are global. So the utilities are mostly concerned about their input/outputs.

Probably for efficience the utilities get a REQUEST call alike:

        GET /list: WHERE name = "hello"

to have the opportunity of do the processing inside.

</comment></comment></comment><comment><USER29> "Maybe we just haven't rethought CLIs since their inception in an environment". And there is a reason for that: backward compatibility. CLIs get used in scripts, and the worst that can happen is to see the script breaking because the command changed.

Let's take the example given in the article: it uses sed (created in 1974), cut (created in 1985), and xargs (created before 2001). All these tools are older than Jira and I'm quite sure that using a version of sed from 10 years ago or the latest one with basic flags will give the same result. CLIs are often ancient pieces of software that started as small projects and grew because features were requested while the way it was working shall not be broken as millions of developers use sed in their bash scripts and expect them to work on any kind of Linux machine, old and new.

For context, I'm working on a CLI for an enterprise product and we got in trouble just because we were changing error outputs. You just cannot do like on a UI where as long as there is a way to perform the same action as before users will not complain.

The second issue is that a CLI is used in two very different contexts: as an application by engineers and as a parts of scripts by those same engineers. This makes it tricky as a CLI developer to know what to do in terms of naming as a daily user will use shortcuts quite fast but a new developer reading a script using our CLI might not understand the purpose of a command. IMO if a CLI has a good documentation (in app and online) you should focus on making your daily users happy as someone seeing the command in a script can check the docs online and hopefully understand what's happening in less than a minute.

<comment><USER30> Random historical note -- xargs dates back to 1977 or 78 -- [https://groups.google.com/forum/m/#!msg/comp.unix.questions/...](https://groups.google.com/forum/m/#!msg/comp.unix.questions/vG2keVnENmo/LkZN5orQrwcJ) has a post in 1988 from the original author saying they wrote it at Bell Labs a decade before, and that it actually predates the Bourne shell itself.

<comment><USER2> Wow, nice find :) I'm a fan of xargs, so I saved it here:

[http://www.oilshell.org/archive/xargs-history- usenet/LkZN5or...](http://www.oilshell.org/archive/xargs-history- usenet/LkZN5orQrwcJ)

</comment></comment></comment><comment><USER31> Humble suggestion: use the terse options when writing iteratively and the long form in scripts that you save to a file. The latter will likely be read by others or yourself in a few months from now, and it could be nice as immediate documentation if you did something fancy with a tool or option that you seldom use.

For instance, I know the handful of options that I personally encounter and use for the "grep" program, but the man page lists plenty that I do not immediately recognize. So typing them out in the script helps a lot with readability.

Going overboard with terseness or verbosity is obviously not helpful to the (human) reader, regardless of the direction.

</comment><comment><USER28> I think there is another post on HN right now about how computers are more like appliances today and no longer as readily programmable as they were before.

And looking at that problem, you realize that a shell is a huge part of the tinkerability of an OS and bash has dropped the ball in that regard. It's like it's frozen in 70s.

We should be moving towards something like a LISP machine where the whole system is exposed through your shell itself. Perhaps, we can start using Chrome dev tools console something like a shell, a good first step might be using typescript for the shell.

</comment><comment><USER32> Short options make it quick and easy to use commands you use all the time.

Your little bashism was quick for me to read because it was compact, scannable, and used popular programs I use frequently (cut, sed etc). Yes, you need to look up the options for programs you don't use often but you need to look them up anyway _because_ you don't use them frequently.

Conversely the longer example you used had longItentifiersThatNeedParsing (and are too long to fit in your fovea) and worse, are easy to accidentally confuse with say longItentifiersThatNeedNoParsing -- an error you are likely not to see when reading the code and an error you might especially use when your tooling has a pop-up of suggested completions.

The gnu approach of long + short options can help; it would be better if getopt() would write a completion grammar into a section of the ELF file that could be mmap()ed and used by readline(), similar to the TOPS-20 jsys that inspired it.

</comment><comment><USER33> Perl allows this. Perl allows easy string stream manipulations, file manipulation, and runs external programs easily with backticks or qx(). As soon as a shell script has more than a single loop and conditional, you can rewrite it in Perl instead, just as terse, more readable and way faster. Just use Perl, the Swiss Army Chainsaw.

<comment><USER34> Yes! Perl is what I turn into when I have a Bash script that is becoming too big or too complex. It's easy to to turn Bash code into bad Perl code that is still better than Bash. From there, it's easy to create a maintainable Perl script that is more elegant, concise, and maintainable. It's a fantastic glue language that will tie all the components of your project neatly.

And if you are thinking "yeah, but then I need to learn Perl", don't worry. The amount of Perl you need for translating Bash into Perl can be learned in a few afternoons.

</comment></comment><comment><USER35> They have this. It's called powershell and I hate it. If you're going to write code, use a real programming language.

<comment><USER36> Can you elaborate on this?

I've been a huge fan of PowerShell ever since I started using it (over two years now) and it's my go-to scripting language on my workstation. You can write integrations in the form of modules - VMware has Power CLI, Azure and AWS both have great PowerShell modules.

Why would you say it's not a real programming language? It's as powerful as Bash and seems to do the job quite nicely in most cases for scripting.

<comment><USER35> Oh. It's certainly better than Bash, but it's still better to use Python or C#. Powershell makes so many weird decisions and it's so verbose and wordy that it becomes unreadable in the opposite way of Bash. I don't think the shell _scripting_ space is desirable. Either you should be typing in commands manually or you should be writing a program. Powershell and Bash exist in a weird space in between them and wind up being crappy programs rather than readable shell commands.

</comment></comment></comment><comment><USER14> I remember sitting down at a VMS terminal for the first time (a university library's terminal had trouble with its OPAC and dropped me into a logged in VMS shell). In fifteen minutes I had learned how to work with it, had the machine show me the university's network, and started to feel comfortable. I cannot imagine a similar experience if exposed to a Unix shell for the first time.

</comment><comment><USER37> The poster is holding a line of bash to the standard of code and is illustrating that readability should be the goal and a way of bringing bash commands to a standard of readability for something like a PR. Readability is really there to show _intent_ I would say though that if you are bringing this to the code standards of today then this should really be wrapped up in some kind of unit test ([https://github.com/sstephenson/bats](https://github.com/sstephenson/bats) )for it to pass the PR. That would make the code a bit more maintainable and can be integrated as a stage in your CI/CD pipeline.

If we do that then the intent would be clarified by the input and the expected output of the test. Then then the code would at least be maintainable and the readability problem becomes less of an issue when it comes to technical debt.

I've done this plenty of times with my teams and its certainly helped.

<comment><AUTHOR> That's interesting. Hadn't thought about the testing angle. Thanks for sharing this

</comment></comment><comment><USER38> Sounds like the author wants the VMS shell with its concept of command tables and attributes that provide fully consistent syntax and standardized online help. It even makes it nearly trivial for any utility to provide its own command line that follows all the same syntax, help mechanisms, and conventions.

</comment><comment><USER39> > Consider another way we might express the same functionality in a language > like javascript

If only someone would write some sort of practical extraction and reporting language, that would really be a killer app for these types of operations.

I can't believe nobody ever thought of that. Definitely a good idea for a startup.

<comment><USER40> You mean like awk?

</comment></comment><comment><USER41> Ugh, I don't want to type that much at a CLI. Terseness is a virtue

<comment><USER42> Terseness can be a virtue, but when you arrive at ${#arr[@]} to get the length of the the array _arr_ , you're practically dealing with hieroglyphs.

<comment><USER41> Which is fine with me. I have always hated how people seem to want computers to be more human-like. It's a computer, not a human being. I like that this stuff takes some skill to learn/use

</comment></comment></comment><comment><USER43> I think the larger issue is that shell scripts are intrinsically bad for writing readable code.

Consider the "cut" line in the shell script vs the "map" line in the JS script. The map line is easy to understand because it uses a chain of simple functions (map, split, array access, and lastly trim). The "cut" line has to cram all of this functionality into a few command line arguments instead of composing basic building blocks together.

I mean look at this: What does "only delimited" mean, what does "fields" mean, I might just be an illiterate boor but I don't remember what delimiter means off the top of my head (something like seperator, I assume).

cut --only-delimited --fields 2 --delimiter '|'

The JavaScript version is easier to read because it uses fundamental building blocks in the language that are

1\. Super intuitive. (Split seems pretty easy to understand, especially when you know the input is a string, similarly everyone knows [1] means array access).

2\. Widespread. You have probably encountered all of those JS functions before, I'd say the chance of encountering the "cut" utility is a bit less.

Summary: Shell just fundamentally sucks because it outsources a lot of functionality to various executables, each which have their own command line arguments. The ideal method is to use a programming language with consistent, composable, building blocks.

</comment><comment><USER44> I feel like in my time we wanted to learn everything. These days people don't find as much value learning everything and prefer as little new knowledge as possible.

<comment><USER45> In the current time, there's a lot more to learn. Few people are going to hire you based on your expertise in bash or UNIX command line utilities.

<comment><USER44> It's a skill that will get you out of trouble, allow you to do things others can't and because of that it might get you promoted which will get you hired.

<comment><USER45> In my experience, while what you say is true, if I were to rank the skills that "might get me promoted", there are far too many that are way higher than this.

Conversely, look around you at those who are at your "level" in the company, or at tech people who are higher than your level. How hard is it to find someone who does not use sed, awk, cut, etc?

<comment><USER44> I've always been a senior developer at the highest level at where ever I've worked. No one I've worked with over the years has ever used those tools. I do and it gives me an edge in response time.

But if you want to move up. Everyone role above senior developer involves dealing with people/managing projects. Those skills get people promoted. More tech skills don't.

<comment><USER45> >Those skills get people promoted. More tech skills don't.

Which was my point.

But frankly, even if I were to rank the tech skills that can get someone promoted, expertise in sed/awk is pretty low.

</comment></comment></comment></comment></comment></comment><comment><USER46> Better IDE support would also help here, if it could annotate what each flag meant for example and provide inline help and autocompletion. The nice thing about shell is the commands are very short and easy to type on the command prompt, PS is too verbose and is cumbersome for that use case and more full featured languages have all the upsides plus better tooling.

<comment><USER47> Powershell has abbreviations (aliases) for common commands and fantastic autocompletion for flags and arguments passed to cmdlets. Where-Object|Format- Table is just ?|ft for example.

Also remember that in PowerShell there's very little munging - half of any serious shell script is sed/cut/awk/tr and so on to munge the output of one command into the input of the next. That more than makes up for PowerShell's individual commands or cmdlets having more characters in.

</comment></comment><comment><USER48> I get that some people don't like or invest in it, but I'm fine with the way the default shells work on macOS, GNU/Linux with coreutils or BSD.

Sure, you can make a version that is usuable by people who aren't normally using it, but then you get the inverse later on where you need a special shell for people that use it a lot and want shorter commands...

There is no one size fits all, and instead of trying to bend what's there to suit a larger group you could simply do what others have been doing and make more 'entry level' shells for those that want/like/need it. There is no reason we can't have both.

p.s. the examples on the webpage are super easy to read, but the javascript ones are probably much more prone to aging and breakage than the bash ones... I'm pretty sure it won't work everywhere, wheras the cut/sed/bash/xargs ones will work anywhere with the utils in de base systems for the past 20 years.

</comment><comment><USER49> It would be interesting to have an option in CLIs that will translate all short options into long options.

This way you can take somebody's

      `cut -sf 2 -d \|`

and turn it into `cut --only-delimited --fields 2 --delimiter '|'

Sadly this would require a convention along the lines of a --whatif --convert- to-long in every CLI ...

</comment><comment><USER50> I'd say the counter example to this is Powershell - if you've ever used it, it's quite verbose and can be less than pleasant to write. I think having both options is the best, when you're getting started it's nice to have verbose, highly self explanatory commands. As you get more familiar with the environment, it's nice to move to something more concise.

Import-Csv -Path $src | foreach { $file = $_.column8 Write-Verbose "Writing to $file" Export-Csv -Path (Join-Path -Path $dstDir -ChildPath "$($file).csv") -InputObject $_ -Append -Encoding ASCII -NoTypeInformation

<comment><USER26> At the interactive shell, the verbosity collapses:

        ipcsv $src|group column8|%{$_.group|epcsv "$dstdir\$($_.name).csv" -noty -e ascii -v}

The bad part is when writing "good" powershell the verbosity is exponentially worse and it turns into

        try
        {
            if (-not [string]::IsNullOrEmpty($_.Column8))
            {

                $fullPathName = Join-Path -Path $dstDir -ChildPath $_.Column8
                $pathTestResult = test-path -LiteralPath $fullPathName -ErrorAction Stop

                # This is a hashtable of the parameters to a cmdlet
                # the only purpose of this 'splatting' is that
                # powershell commands get too long
                # and can't be line-wrapped in any good way

                $exportParams = @{
                    Encoding = 'ASCII'
                    NoTypeInformation = $true
                    Append = $true
                    LiteralPath = $fullPathName
                    Verbose = $true
                }

                Export-Csv $exportParams
            }
        }
        catch [whatever]
        {

        }

and on and on and on, ugh.

</comment></comment><comment><USER51> I think bash is terse for at least 2 reasons:

1\. Quicker to type repeated variations of commands at a CLI.

2\. Memorization of flags isn't as much a concern since you're at the CLI, you can often easily look up the meanings of options and flags with -h or man pages.

It may be slightly more difficult in the beginning, but once you're familiar, terseness saves significant time.

I would relate shell languages more to vim or emacs in that regards. They have a higher learning curve but pay off in efficiency in the long term.

<comment><AUTHOR> Yeah shame of me for not mentioning the terseness is faster argument.

Do you think that terseness saves _significant time_ as compared to just tab- completing longer flags?

<comment><USER51> It's the only benefit I suppose.

I neglected to think about tab-completion, but I see you mentioned it at the end. I've never used it for bash. It really depends on whether I can guess or remember the first letter(s) to the option. If it's a command I am new to, I'd still need to print out the available options anyways.

</comment></comment></comment><comment><USER52> > Programs must be written for people to read, and only incidentally for > machines to execute.

That's true of programs that are written to be used and maintained over a period of time. Shell programs like that are mostly system configuration and installation scripts; they are not written that often compared to throw-away one-liners that most shell users write every day. I'd hate to use even a regular programming language for the daily tasks, let alone a verbose one.

</comment><comment><USER53> I'd buy the argument that using single-letter flags is confusing, except...

the huge popularity of hot keys in GUIs, etc, which have the additional demerit of not being particularly discoverable or guessable. We accept non- discoverable hot-keys etc in GUIs, so this argument probably results from unfamiliarity.

</comment><comment><USER54> Anyone else put off by camel case at the command line?

Jumping back and forth between JS files and functions in camel case and Unix standard snake case is more confusing for me than memorizing the couple highly used flags.

I sknow I'm being subjective, but we're talking style, so it's all kind of subjective.

<comment><USER55> Powershell is case insensitive. Use the style that resonates most with your heart.

</comment></comment><comment><USER56> On the one hand I understand how it might be harder to read -char cmdline flags. But it does save keystrokes. Nobody does

      for (int iterator; iterator++; iterator < some_val)

That would be quite silly.

<comment><USER45> >for (int iterator; iterator++; iterator < some_val)

Not sure what you're trying to say. That loop will likely not terminate.

<comment><USER56> That's my point. That code is broken but still readable. The OP is trying to equate readability with correctness.

</comment></comment></comment><comment><USER57> Hm.

        | sed 's/ //g'

and

        .trim()

only do the same thing if there are no interior spaces, like filenames for attachments might have.

</comment><comment><USER58> I happen to like the short options though (at least it is my opinion). (Of course, some programs can do both, but some programs only have long options.)

</comment><comment><USER59> the cut, sed, xargs, utilities are available on all major unix derivatives and have a pretty consistent set of command line flags... I don't see why we need to suddenly slap camelCasedParameters on everything because the author needed to read some man pages...

</comment><comment><USER45> This is part of the reason I use xonsh instead of bash.

</comment><comment><USER60> Powershells way of doing CLI is the best way yet

</comment><comment><USER61> Same shit.

</comment><comment><USER62> This might be one of the core reasons why Linux never took off as a Desktop solution. Also looking at the comments here just shows how out of touch people are with the real world...

If you relish in terse commands that don't mean anything to anyone who hasn't been spending their last 20 years working on the command line, then go for it. Just realize that most of us (talking about the already small population that is software developers) are not interested is spending anytime on dealing with this junk. This is not to mention the other 99% of the population who doesn't even know what Linux or Bash is, and good riddance for them...

The JavaScript code the author posted is immediately intelligible to anyone who has been keeping in touch with programming language developments over the past years. It doesn't even matter if you come from C#, Python, JS, Java, etc. It should be familiar to all of them. You might not know exactly what it does, but it seems oddly familiar.

I may be making a leap here, but I would go as far as saying that this very attitude of command-line elitism is the primary reason why Linux has had zero chance to take hold in the Desktop space. The developers have no clue why "normal" people would not want to use the command line (and I am including myself in it) and their efforts of creating a GUI (just look at the junk that is KDE, Gnome and Unity... Proudly sold off as GUI) have been so out of touch with reality, that I can't even.....

Anyway, each to their own. I am mostly using the command line to start a build process. While I am able to do a lot of more advanced stuff, including properly using VIM, I am actually regretting spending the time on learning it. These days I wrote most of my "bash" scripts in Python instead (just to clarify: I write scripts in Python, for which it seems well suited. I don't see Python as a viable choice for creating actual software). There are some scenarios in which Bash is still a better choice, but thankfully they are far and few between.

<comment><USER63> The Linux Desktop has nothing to do with the command line.

And most of the desktop environments are significantly less of a mess than Windows 10's mishmash of five separate GUI styles. Even if I don't like Unity either.</comment></comment>


Chrome helper - <AUTHOR>

What im wondering about is why is does each tab or window in chrome get a helper even when flash isnt really running. Is this also the add-ons running? <comment><USER2> You really need a [Ask HN] and some meaningful text rather than "Chrome Helper"

Something like:

[Ask HN] Why does each tab/Window get a helper?

As for the answer, I don't know. It's probably something to do with sandboxing.</comment>


Predictive CPU isolation of containers at Netflix using a MIP solver - <AUTHOR> https://medium.com/netflix-techblog/predictive-cpu-isolation-of-containers-at-netflix-91f014d856c7 <comment><USER2> For a related work by Google (in 2013), see "CPU performance isolation for shared compute clusters": [https://ai.google/research/pubs/pub40737/](https://ai.google/research/pubs/pub40737/)

</comment><comment><USER3> I'm one of the author of the post, happy to answer any question.

<comment><USER4> In my experiments with MIP there was a dramatic performance difference between free and non-free solvers. Did you also experience this?

<comment><USER5> I worked with MIPs for 8 years and commercial solvers have always been several orders of magnitude faster/better than open-source solvers.

This is generally true for domain-specific software -- unlike general purpose software, incenting a small pool of specialized talent to make open-source contributions is always hard.

The key to high performance in MIPs comes from having good heuristics, not necessarily from improving the basic algorithms (the algorithms are pretty standard -- simplex or interior point). Finding effective heuristics is hard and tedious, but they make a significant difference in solution speed. For instance, naive Simplex may take 40 minutes to solve a problem but with heuristics the solution time might be 5 seconds.

That said, Cbc _is_ competitive for smaller problems, and here's the thing: many production sized problems aren't that big -- it really depends on your problem domain. I've deployed commercial solvers on Cbc (30k variables/constraints) and it was more than adequate.

I don't have any details on this, but Gurobi (a best of class solver) also offers an on-demand cloud SaaS which you can pay for on demand [1]. The economics of this may work out for some types of problems.

[1] [https://www.gurobi.com/pdfs/user- events/2017-frankfurt/Gurob...](https://www.gurobi.com/pdfs/user- events/2017-frankfurt/Gurobi.pdf)

Also, if you're in academia, you can get Gurobi/CPLEX licenses for __free __(yes). My research group in grad school didn 't spend a cent on these solvers, and we still got a taste of best-of-class solution performance (that's how they get you :).

</comment></comment></comment><comment><USER6> I love this type of work, the final analysis shows a significant change but one that I've had difficulty with in the past. Decrease your variance and your 99 percentile and your going to see gains even if you see an increase in your volume of times near the median.

So often we see projects that talk about cutting costs by order of magnitudes but this one is taking an order of magnitude of pods greater than most of what we will do and reducing it fractionally

</comment><comment><USER7> Maybe not applicable to this article, but since caches and numa was mentioned...

Has anyone studied effects of CPU allocation on cache coherency performance (different L2 caches talking to synchronize data) and in the end overall system performance?

<comment><USER8> Intel VTune Amplifier can help you with that, although it has to be tested with each release of your code to get the most juice out of it as every application is different in terms of Computation, Disk IO and Network IO.

[https://software.intel.com/en-us/vtune](https://software.intel.com/en- us/vtune)

</comment></comment><comment><USER8> Setting CPU affinity to process worked for me. I always use this trick in my DevOps script for deployment.

[https://linux.die.net/man/1/taskset](https://linux.die.net/man/1/taskset)

<comment><USER9> What is the benefit? Does it run faster, or more consistently?

<comment><USER8> Yes, I have seen upto 8% improvement in execution time. Here consistency is about having less L1/L2 cache misses

</comment></comment></comment><comment><USER10> Anyone has an experience running openfoam in the containers? —cpuset-cpus gives me huge performance hit. It's painfully slow if I allow 16 cores to docker, while running it directly in VM with 16 cores it's much faster?

</comment><comment><USER11> Why not just buy some hardware to run these jobs rather than doing all this work to reduce the aws bill a couple percent?</comment>


Hope of cancer cure offered by 'decoy' molecules designed to kill tumours - <AUTHOR> https://www.express.co.uk/life-style/health/1115928/cancer-cure-research-decoy-molecules-kill-tumour <comment><USER2> [https://www.youtube.com/watch?v=1tteYZfMat4](https://www.youtube.com/watch?v=1tteYZfMat4)</comment>


Wait, is dark mode bad for productivity? - <AUTHOR> https://zapier.com/blog/dark-mode-bad-productivity/ <comment><USER2> So good article! That is again a good example of the "hype" based features that big tech companies are pushing on us without real scientific justification.

<comment><AUTHOR> I would argue that the majority of "AI" is also hyped. It's neither A nor I!</comment></comment>


Spiritual Wisdom Summary for the Modern Age - <AUTHOR>

When the direct connection to Self is hidden behind the firewall of ignorance, access the universe through the proxy server God, using a master-slave connection. <comment><USER2> What if I'm Hindu? Who ya gonna call?</comment>