The bloodbath continues: Netflix cancels Daredevil after three seasons - <AUTHOR> https://arstechnica.com/gaming/2018/11/the-bloodbath-continues-netflix-cancels-daredevil-after-three-seasons/ <comment><USER2> They discontinued their best Marvel show, after one of the best seasons of superhero television ever. I don't see the logic.

<comment><USER3> "Best" these days is all about sensory stimulation to the max. Over- stimulation till you feel like you need to go sit some where quiet to calm yourself down.

So if I know you are going to feel pain/love/respect/fear/doubt based on certain triggers and I am competing against others who are triggering you the same way what are my options?

Turn the dials up on all the triggers. Maximize stimulation as much as possible. This is happening from porn to sports to politics to news to games. To TV.

But when everyone is doing it you start seeing the patterns. There aren't that many. The dictionary of all possible patterns is more or less complete.

The cancellation is for the same reason, they can't really keep making more Star Wars or Avengers or Harry Potter movies for too much longer because they have exhausted all possible ways in which one guy can kill another guy. The audience has seen it all.

They just have to start again with a new different looking slate to produce the same stimulation.

<comment><USER4> I think there is lot of scope for content creators to use those triggers to produce effects beyond stimulation. Stimulation is just low hanging fruit.

Inspiring people, making them feel more empathy, act with compassion, sparking imagination and creativity etc is all possible if content creators move beyond just sensory stimulation.

Imagine a show that doesn't just make people feel good but do good. I think as data pours in, such things will start happening. They happen right now mostly through serendipity rather than actual planning and engineering.</comment></comment></comment>


Confessions of a Car Salesman (2001) - <AUTHOR> http://www.edmunds.com/car-buying/confessions-of-a-car-salesman-pg2.html

<comment><USER2> As someone who was a car salesman for 8 years, this was surprisingly accurate. Normally these style articles are just hilariously wrong, but I was impressed by the accuracy here. I will say though, the profit levels that Edmunds and other companies suggest just aren't levels a salesperson can survive at. Most dealerships have a minimum commission around $100, and if you're buying the car at the prices you see recommended online, that is all the salesman will make. Increased profit is often a question of survival. If you know you're only going to sell 10-12 cars a month on average, they can't all be for $100 commissions or you're going to starve. Even the "unfair" deals, where he made $300-$500 from a sales persons perspective is about as low as they want to go.

I think there really does need to be some kind of change to the process here, sales people just literally cannot survive on what Edmunds would consider a fair price. As a sales person though, I can't tell you how many times someone had a fair price worked out before coming in to the dealership and then expected to negotiate more. Most people just seem to expect it, so you're in a weird limbo land where it's difficult to A sell a car to most people without a big negotiation, and then at the end the same people complain they have to negotiate, but had you just given that price up front, they never would have bought. Lots of interesting psychology :)

<comment><USER3> The question I'd ask is, why do I need the salesperson at all? I know exactly what I want when I buy a car. For my last two cars, I sourced and specified the manufacturer option codes for my order.

The role of a salesperson is to convince someone to buy a product. If I am already convinced, why should I have to involve this person in my transactions?

<comment><USER4> You don't, the dealer does. I sold cars for a short while. The dealer makes money by introducing a spread between what he paid for it (minus bonuses) and what you'll pay (plus financing). They are middlemen pure and simple, something information technology is exceptional at deprecating. The reason the major brands don't have company stores like Tesla is manufacturers don't have to hold as much of a risk with inventory and dealers are well lobbied.

<comment><USER5> The main issue here is the lobbying component of the dealerships. A lot of states have mandatory purchase the car from the car dealer mandates, thereby requiring a system in which the dealer makes enough money to continue their efforts.

<comment><USER6> The rest of the world has car dealerships too, and as far as I know has no mandatory purchase rules. As far as I can make out car dealers make so little money in Europe that it is not worth disintermediating them, but I may be wrong.

</comment></comment></comment></comment></comment><comment><USER7> If you enjoyed this, worth checking out This American Life episode: 129 Cars [[http://www.thisamericanlife.org/radio- archives/episode/513/1...](http://www.thisamericanlife.org/radio- archives/episode/513/129-cars)].

<comment><USER8> Thanks; I enjoyed it. Also, it was interesting that the writer of this Confessions series worked as a car salesman and ended up no longer blaming the salespeople for pushy tactics etc., but rather the sales managers and dealership owners. Listen to that podcast and you come away feeling that those people are in basically the same boat, under pressure from the manufacturers.

</comment></comment><comment><USER9> Lots of good arguments against buying a car (esp in cities) or buying a gas car (tesla) or buying a new car from a dealer (massive depreciation), but there are cases where it makes sense.

The key is to be an informed buyer, and to break out separate parts of the transaction and analyze them individually.

Financing from your credit union, in the absence of a manufacturer-driven promotional financing rate, is going to be better.

You'll get more for your car selling it on Craigslist or whatever (although, more hassle).

Various services exist to negotiate fixed discounted prices for cars themselves: costco, usaa, etc. Founderscard has an audi MSRP discount, too. You might be able to do better negotiating in person at a dealer if you know the structure of manufacturer incentives -- sometimes selling a car at a loss makes sense because it pushes them over a threshold -- but that's a lot harder in a place like the Bay Area and for popular cars (VW TDI when gas was expensive, audi and bmw now).

The great deal that was the certified preowned seems to have become popular enough that it's no longer such a deal.

I really hope my car lasts me another 2-3 years; either get a Tesla then, or a 535d in Germany.

</comment><comment><USER10> See also the 2009 edition: [http://www.edmunds.com/car-buying/confessions-of- a-car-sales...](http://www.edmunds.com/car-buying/confessions-of-a-car- salesman-updated-for-2009.html)

</comment><comment><USER11> The most egregious cost with these cars is not the thousand or two over in profit to the dealer, but rather the massive depreciation over the first two years. That's a substantial expense that almost everyone overlooks and one that can be easily avoided but just buying something a few years old.

<comment><USER12> Eh. Certified Preowned and various information sources have reduced a lot of the information asymmetry risk of buying late model/low mileage cars and therefore what was effectively a risk premium has shrunk as well. I'm not a particular expert and doubtless there are individuals who get good deals if they put in a lot of legwork and buy from individuals. However, when I've looked, at least used cars from dealers weren't any particular bargain.

<comment><USER11> Dealers don't list their used car prices at attractive prices, but they will come down. From the research of done when buying our past two used cars (in 2013 and earlier this year), the information asymmetry was still plentiful. Dealers get cars from auctions, off-lease, trade-in, etc. You have no idea what their cost actually is, unlike with new cars.

</comment></comment></comment><comment><USER13> I was a "online sales director" for a small chain of new and used cars for about a year.

Never buy a car new unless you have to. If you're buying the car new you shouldn't focus on the purchase price, but the value for your trade in and your APR.

Most used car sales generally only brought in $1,000-$3,000 in profit. The dishonesty in the business doesn't revolve around the pricing, it's in the details of the cars. Salesmen will lie about resale values, maintenance records, previous owners and so on.

My advice is to identify 2-3 cars you'd like and then buy that car with 30K-50K miles on it no more than 3-4 years old. You'll still be able to get a low APR, and you'll have cashed in on a car that will hold it's resell value better than a brand new car.

</comment><comment><USER14> Previous discussion: [https://news.ycombinator.com/item?id=3779735](https://news.ycombinator.com/item?id=3779735)

It is an interesting article, even though things may have changed since it was published.

</comment><comment><USER15> I sold cars for a month back in my early 20s. This article is spot on, right down to the training class and not knowing how much you REALLY make on each deal. Half of the customers wouldn't qualify and the other half didn't realize how math works so you can't get a $30k car for $300 when you are $2000 upside down on your trade with no money down.

</comment><comment><USER16> I wonder how things have changed in the last 14 years. I bought a car a couple of years ago, and the "Internet price" is now a thing. I found it harder to negotiate numbers since now "no haggle" means that they have the same high prices as "haggle" places, but are just not willing to go lower on them.

</comment><comment><USER10> Oddly, the "carsdirect.com" mentioned here has evolved into Internet Brands, a media behemoth that owns a whole bunch of forums. [https://en.wikipedia.org/wiki/Internet_Brands](https://en.wikipedia.org/wiki/Internet_Brands)

</comment><comment><USER17> I've never bought a car from a dealer. Has the Internet affected car selling very much since this article was written? The author mentions the beginning of some trends like with carsdirect.

<comment><USER18> It's very frustrating, I bought three over the last couple years. I think the biggest help to consumers is TrueCar.com which basically uses the information they gather about prices people recently paid for cars to negotiate a fair price for both parties. Whenever I mentioned TrueCar the salesmen were kinda disappointed because they knew they couldn't squeeze any extra money out of you. I started a website to help people get good deals on cars and then just decided to quit because TrueCar was efficient enough. Even the dealers that didn't participate still respected their pricing. At that point it was just a question of making sure not to get screwed on the financing and trade-ins.

<comment><USER19> I had never seen TrueCar.com. Thanks for that. I bought my first new vehicle 4 months ago and have felt like I got screwed every since. Turns out, I actually got a decent deal.

</comment></comment></comment><comment><USER20> Can someone summarize the secrets to me? I noticed the article was 11 pages long.

<comment><USER12> I'd probably word grecy a bit differently. As much as possible, separate the purchase from the financing from the trade-in. Easier said than done for some to be sure, but get an idea of alternative payment options if you don't have the cash or existing line of credit. And know what you'd be willing to take for a trade given what think you think you could get for the vehicle on Craigslist or donating it. And, of course, have your max price for the vehicle in question given invoice price and other factors.

<comment><USER21> One thing to keep in mind, if your trade in has significant value, is that your trade in amount reduces the tax you pay on the new price. For example, if you buy a $25000 car, and have a trade in value of $10000, you only pay tax on $15000.

<comment><USER12> Good point. In my case, I basically only buy a new car when the old one is on its last legs so we're talking about $1K-$2K at most.

</comment></comment></comment></comment><comment><USER22> Anyone know if there is an Edmonds.con variant in Germany?</comment>


Only humans, not computers, can learn or predict - <AUTHOR> http://techcrunch.com/2016/05/05/only-humans-not-computers-can-learn-or-predict/ <comment><USER2> > Given the fact that humans do have this inherent capacity and ability to > imagine and create, future changes in markets or geopolitical conditions > (that are mostly due to human actions) cannot be predicted based simply on > past events.

Does the author mean there is some non-neurological reason we are able to 'imagine and create'? The neurological connections in our brains certainly are a function of 'past events', even in the case of creativity. There could be we have some random number generator in our brains that somehow create new and unexpected connections, which we then call imagination, but I see no reason why this cannot also be implemented in a computer.

</comment><comment><USER3> _Machines as simple as thermostats can be said to have beliefs, and having beliefs seems to be a characteristic of most machines capable of problem solving performance._

John McCarthy : Ascribing Mental Qualities to Machines, 1979

[http://www-formal.stanford.edu/jmc/ascribing/ascribing.html](http://www- formal.stanford.edu/jmc/ascribing/ascribing.html)

</comment><comment><USER4> not enough data</comment>


Why is Virgin America so Cool? - <AUTHOR> http://geoffreynuval.devhub.com/blog/526362-why-is-virgin-america-so-cool/ Virgin America knew that the only way to compete in the commoditized service of air travel, where competitors are forced to compete on price, was to invest in elevating the experience itself.  That's why they're so cool (and financially successful) <comment><USER2> If you're interested in learning the philosophy behind Virgin from start to finish, I highly recommend Richard Branson's _Business Stripped Bare_.

I just finished reading it a couple weeks ago. It's a quick/enjoyable read, but also contains quite a few valuable takeaways that are applicable to any business.

[http://www.amazon.com/Business-Stripped-Bare-Adventures- Entr...](http://www.amazon.com/Business-Stripped-Bare-Adventures- Entrepreneur/dp/1905264437)

(Unrelated, and this one obviously isn't, but what's the HN stance on affiliate links to sites like Amazon?)

<comment><USER3> This book is great. Branson was the first big-named businessman to convince me that "business types" weren't all backstabbing fat cats.

<comment><USER2> I haven't finished it yet, but I've liked _Call me Ted_ in a lot of the same ways as Branson's book, so far.

<http://www.amazon.com/Call-Me-Ted-Turner/dp/0446581895>

</comment></comment></comment><comment><USER4> Virgin is cool _unless_ you're a graphic designer/photographer/interior designer/etc. and you want to get some work done on the jet -- those purple/pink lights throw off the perceived color balance and screw everything up. If Virgin America were _RELLY_ cool, they'd provide a downloadable color profile for working inside their cabins. :-)

BTW, your link points to the main page and not the virgin post at the moment.

<comment><USER5> Correct link:

[http://geoffreynuval.devhub.com/blog/526362-why-is-virgin- am...](http://geoffreynuval.devhub.com/blog/526362-why-is-virgin-america-so- cool/)

</comment></comment><comment><USER6> I can only comment on my Virgin Blue (low but not cutthroat budget Australian airline) experience but I have to say that the company has completely embodied the Branson attitude as described in his books. For instance we've been an hour late to a flight (that was fortunately delayed) and not only did they let us on the plane, but they managed to let us check in an unexpected baggage item (they security cleared it of course) - I have no idea what the usual domestic American carrier is like but this rule-bending on favour of the customer and common-sense (humans at all levels to paraphrase Branson) is unheard of on other (particularly traditional) carriers where, for example, you can lose your flight without refund if you are only 25 minutes early to your flight instead of 30 minutes.

Some other comparison points:

\- "Web check-in" allowing you to arrive anytime up to the boarding of the plane (if flying with purely carry-on luggage) instead of having to arrive an arbitrary time before departure because of inefficient passenger processing.

\- Friendly, bouncy and joking flight staff versus off-putting and critical drones who seem put out at the slightest request.

\- Modern aircraft with simple amenities like screens for every seat versus tired old planes from the days where lack of competition and government monopolies dominated the industry.

\- Reasonable fares without sacrificing quality versus either dated but comparable quality at a higher price or true "budget" where you sacrifice both quality and patience for a price that is often pretty close after hidden fees (e.g. A fee for booking, a fee for paying and a fee for paying via credit when this is the only accepted option).

</comment><comment><USER7> My personal experience with VA, unlike other domestic carriers in the US, is that they don't treat you like it's a privilege that you get to fly at all. Domestic carriers treat customers as if they are doing _them_ a favor, rather than providing a service to a paying customer that you hope will come back again.

This is the same way Southwestern does it too. It's amazing how some politeness can go a long way to brand loyalty in the US air market.

<comment><USER8> There is no such airline as "Southwestern".

Anyway, I love the legacy carriers. Last year, I flew about 110,000 miles on American, all economy. For that, I now get free upgrades to First Class, the ability to use the flagship lounge, special check-in and security lines, free stuff on board, and lots of other perks. Every time I travel, it's a joy -- there are no lines and the customer service is amazing. The service on the plane is nice too, even when I'm in economy. American makes me feel like I'm their only customer, and that they want my business.

So while it's true that the legacy airlines don't care about Joe Pricecompare who flies once a year, they do care deeply for people who consistently bring them revenue. (I miss this treatment in other industries, in fact, as I tend to be very loyal.)

Now it's true that my experience is atypical of the majority of the flying public, but it's typical of the people that keep the airlines around. The reality is that the average traveler is very hard to make money off of, and the legacy carriers just gave up. Bad for you, good for me :)

</comment></comment><comment><USER9> I hate when tech people do this. The source that the coolness is paying off is an Owen Thomas article about ONE quarter of profitability (5.1M) in 2009? I'd say the verdict is more than still out.

That being said, Virgin is interesting in that they are attempting to compete on brand instead of on price. Part of the problem with all the other airlines is that everybody flies whichever is cheaper, leading them all to race to the bottom.

There is more than enough meat in the concept above to have a discussion. We don't need to hold it up as PROOF OF CONCEPT with flimsy evidence just yet.</comment>


House panel votes to split Air Force, create new U.S. Space Corps - <AUTHOR> https://federalnewsradio.com/defense-news/2017/06/house-panel-votes-to-split-air-force-create-new-u-s-space-corps/ <comment><USER2> Sounds like somebody at USAF Space Command wants a promotion.

This seems decades late. The USAF has no manned space capability. The U.S. Government once owned the Space Shuttles. They had astronauts. The USAF once had a Space School. That's all gone. Now, they just buy commercial rocket launches.

If anything, the reorganization the USAF needs is to lose the close air support mission, and the A-10 Warthogs, to the Army. The USAF keeps trying to kill off the Warthog, and doesn't want to get involved with smaller fixed-wing aircraft for close air support. The Army needs that low-level aerial firepower. They need it from affordable aircraft they can use in quantity, not rare, overpriced F-35s. There's an old deal between the Army and the USAF, the "Key West Agreement", that the Army would stay out of fixed-wing aviation and only use helicopters. That needs to be looked at again.

(The Marines have their own air, and it works out well for them. Marine air and ground forces tend to coordinate better than USAF/Army combos.)

<comment><USER3> I imagine that the not-too-distant future of close air support is drones with guns and rockets. These could potentially be operated by soldiers on or near the front lines. It's not too much of a stretch to imagine a soldier with a tablet tapping on things for the drone to shoot at.

Not needing a pilot could make them smaller, cheaper, and able to enter (and remain in) dangerous areas in a way a helicopter or plane never could.

This seems like something the Army could operate themselves.

<comment><USER4> Given the choice between a drone+iPad and an A10 warthog, I'd pick the warthog all day every day. That said, I doubt it's an either or thing.

</comment></comment></comment><comment><USER5> _... because we have to defend the ehh hmmm satellites against cough ehm ehhh other satellites._

Nothing like a fourth branch of the armed forces to increase the biggest military budget in the world [1] by another few dozen percent.

[1] From [https://en.wikipedia.org/wiki/List_of_countries_by_military_...](https://en.wikipedia.org/wiki/List_of_countries_by_military_expenditures)

      1. US     611 bn
      2. China  215 bn
      3. Russia  69 bn

<comment><USER6> Aren't those all about the same as a percentage of gdp?

<comment><USER7> From the same table:

      1. US     611 bn (3.3% of GDP)
      2. China  215 bn (1.9% of GDP)
      3. Russia  69 bn (5.3% of GDP)

</comment></comment></comment><comment><USER8> This is a fall in line bill. In my office on Capitol Hill that was our name for legislation that leadership has agreed to, is all ready to go, and there's little to argue that will go anywhere so...just fall in line. Interesting footnote to history: The Republican leadership, from 94 - 06, steamrolled over everyone with legislation. When the Democrats took over from 2006 - 2010, they turned the tides and began ramming bills through without giving much, if any, time to read and analyze. A Republican pledge after they won big in 2010 was to mandate posting of a bill to the web three days prior to debate on the Floor, and other "time to read" ideas. I guess we've come full circle to Republicans preventing Democrats from reading. I'm afraid to see what the Democrats do when they eventually take over; the cycle of things.

</comment><comment><USER9> Why, in this day and age, is the US military organized along a structure (Army, Navy/Marines) based on the Elizabethan English military organization (I recognize the USAF was spilt off to avoid a battle between Army and Navy)? For that matter why are dress uniforms based on obsolete English gentlemen's dress?

A bit of rethink based on objective/mission seems well overdue. The 1940s reorganization that lead to the Department of Defense papered over the structural problems.

<comment><USER10> > _For that matter why are dress uniforms based on obsolete English gentlemen > 's dress?_

This is getting way off topic, but can you give an example? The Navy officer service-dress blue uniform is basically a business suit with gold-colored buttons and gold sleeve stripes; it's been pretty much the same for probably a century now. [0]

[0] [https://en.wikipedia.org/wiki/Uniforms_of_the_United_States_...](https://en.wikipedia.org/wiki/Uniforms_of_the_United_States_Navy#Dress_uniforms)

<comment><USER9> Indeed, service dress and full dress are essentially frozen in the same time as the business suit. Essentially we are still under the influence of the Prince Regent's buddy Beau Brummell. At least the necktie ("cravat") has an actual military origin. But the split into three dress uniforms still apes ancient sumptuary laws and the (thankfully obsoleted) structure of officers coming from the noble and gentle classes and the infantry/sergeants from the lower classes.

Then again the whole white wedding / white (instead of seed) cake weddings come from Victoria.

But it cracks me up to see, say, North Korean generals in uniforms that really just look like Regency clothing!

</comment></comment></comment><comment><USER11> OK, now I _totally_ want to go to what ever academy they open up for this branch and officially become a Space Cadet! :-)

More seriously, this isn't much different that the Army Air Corps becoming the Air Force, logistically it opens up a branch that can have strategies and priorities that are not constrained by its original branch (the original Air Corps was constantly arguing with the Army over what was more important, tanks or airplanes, for example). It also opens up a bunch of jokes for late night comedians like "Look, it is a new customer for the F35 Joint Strike Fighter, now its required to operate in a vacuum!"

</comment><comment><USER12> Looks like the Senate is in disagreement with the House on this:

[https://www.govconwire.com/2017/06/despite-disagreement- hous...](https://www.govconwire.com/2017/06/despite-disagreement-house-moves- forward-on-creation-of-u-s-space-corps/)

> The Senate Armed Services Committee isn't calling for a Space Force in its > version of the NDAA; and is instead stressing the importance of cyber > warfare and a more conservative approach to spending.

</comment><comment><USER13> Meetings and sub-committee hearings on Space Command... but no time for the same on healthcare... Not trying to start a discussion, just noting the irony.

<comment><USER14> National defense is a constitutionally mandated function of the federal government.

"Healthcare" is not.

</comment></comment><comment><USER15> This seems weird and premature. We will probably need a "Space Corps" _eventually_ , but doing it now when the technology is still in its infancy, instead of being able to leverage the manpower of an existing service, seems unhelpful. Making the Air Force its own thing, instead of part of the Army, was a good decision in 1945 but would've been dumb in 1912 too.

<comment><USER16> Actually, I think they should go the opposite way: they should eliminate the Air Force, and make it part of the Army again. The AF was split off because of the Cold War, and is just a relic of that time. No other modern military force has a separate "air force", because having it separate only complicates things when conducting a conventional ground war. For a while the Air Force even thought they were going to make the Navy obsolete, because they wanted to rely on ICBMs and long-range bombers for everything.

<comment><USER17> > No other modern military force has a separate "air force", because having it > separate only complicates things when conducting a conventional ground war.

Besides the US: Turkey, Syria, Russia, Israel all off the top of my head have air force and ground army (along with, at least, a navy) separate under one "Armed Forces" command.

What modern air forces operate as part of the army, rather than separately (as most navies do)?

<comment><USER18> The big one is China, where all the services are technically branches within the People's Liberation Army: [https://en.wikipedia.org/wiki/People's_Liberation_Army](https://en.wikipedia.org/wiki/People's_Liberation_Army)

<comment><USER16> That really doesn't sound any different than the US, it's just different naming. In the US, all four services are branches within the "Department of Defense". So US DOD = China PLA.

To properly compare, you need to look at whether the air force has the same level of autonomy from the ground army as the navy does. If it does, it's just like the US. If not, it's not.

</comment></comment></comment></comment></comment><comment><USER19> SciFi usually base military in space based on the navy, I wonder if this was considered or even makes a difference?

<comment><USER20> I'm guessing that the sci-fi practice was due to the sociological similarities between spacecraft crews and ship crews on isolated, long-term voyages. At present, the US Air Force has been responsible for most high-tech concerns including cyber warfare and space warfare, so it probably was the least organizationally disruptive to bring the new branch in alongside the AF.

<comment><USER21> plug for project rho! They have some discussion of sci-fi military organization (and nine thousand other things, seriously, it's the TV Tropes of sci-fi)

[http://www.projectrho.com/public_html/rocket/military.php#id...](http://www.projectrho.com/public_html/rocket/military.php#id --Organization)

</comment></comment></comment><comment><USER22> Militarization of space notwithstanding, this could be great news for the spaceflight industry as a whole. A lot more contracts handed out for launches and orbital infrastructure, as well as "normalizing" space travel would encourage investment in an industry that has been mostly dominated (and still is) by government entities.

</comment><comment><USER23> Curious how this would affect private ventures like SpaceX?

<comment><USER24> It probably means more money for the space industry and other government contractors, which includes SpaceX.

</comment></comment><comment><USER25> Uh... what?!

      The bill would order the Defense Department to establish the
      new corps by January 2019. It would be a distinct military
      service within the Department of the Air Force, in much the
      same way the Marine Corps operates as a service within the
      Department of the Navy. The Secretary of the Air Force would
      oversee both the Air Force and the Space Corps, but the new
      chief of staff of the Space Corps would be a new four-position,
      co-equal with the chief of staff of the Air Force. DoD would
      have to deliver reports to Congress in both March and August
      of next year on the details of how it plans to set up the new
      service.

Wow. Out of fucking nowhere.

<comment><USER26> if i had to guess, i'd guess this is 'out of' lobbying by big govt contractors who want another budget pool, and MIL insiders pushing for this.

Right now airforce satellites for star-wars type initiatives and airforce refueling tankers all fall under the same budget, while serving very different organizational needs. conversely this is why 'innovation' arms/skunkworks get created... because the mothership moves too slow and has too many competing priorities and budgets to innovate and get out of its own way.

</comment></comment><comment><USER27> Welcome to the militarization of space.</comment>


Ask HN: If UIs can be patented, why not APIs? - <AUTHOR> I'm trying to better understand the Oracle vs Google patent lawsuit. It seems like the dev/HN community has overwhelmingly come down on the side of Google, and the most common justification I hear, is that "Google might have copied the Java API, but they didn't copy any of the implementation. They reimplemented the entire thing themselves. Therefore, it's fine." The corollary here seems to be that APIs can't/shouldn't be patent-worthy - only the implementation should be protected.
This seems somewhat contradictory with the fact that UIs/UXs are frequently patented[1], and most people don't have a problem with it. If someone made a phone whose user interface was a clone of iOS, most people would agree that Apple would have a valid legal case against the copycat.
We recognize that a major portion of innovation comes not just from implementation, but also from elegant interface design. Hence why User Interfaces are deemed patent-worthy. So why not programmatic interfaces in the form of APIs as well?
[1]: http://techcrunch.com/2015/08/03/swipe-to-patent-design-patents-in-the-age-of-user-interfaces/ <comment><USER2> _and most people don 't have a problem with it_

I haven't found that to be true at all. Look at all the furor over the "one click" patent that Amazon got. I don't know anybody who thinks that patent should have been granted.

Anyway, I think your metaphor is too jumbled to be meaningful. A "user interface" is not the same thing as a "programming interface" (eg, an API) and I don't see any intrinsic reason that they should be treated the same.

Also, note that in the end, most of the Google/Oracle case came down to issues of copyright, not patents.

Further note that the issue of protecting UI/UX is hardly a settled issue. See: [https://en.wikipedia.org/wiki/Look_and_feel#Lawsuits_over](https://en.wikipedia.org/wiki/Look_and_feel#Lawsuits_over)

</comment><comment><USER3> It is easy to replace one design with another and people want to be unique in this aspect anyway.If someone would create a calendar app, and you would like to replace it with another, its perfectly fine if visually they would be slightly different. Copyright and design patents do not block ability to create functional equivalents, because people do not rely on design being _exactly_ the same. API's are different. If you provide an API, then all clients must use _exactly_ the same "design"(function names, arguments, error codes, everything). If someone else would want to provide alternative implementation, they _can not_ change _anything_ , otherwise clients will stop working and need to be changed. So the concepts may be similar, but implications are entirely different.

</comment><comment><USER4> IANALblahblahblah

Design patents cover ornamental aspects, and can be invalidated if those aspects provide a functional utility. You can't cover round wheels under a design patent, but you could cover purple wheels with one.

You can remove Apple's patented animations and icons from your clone of their software and the software would still function.

You can't remove this_Is_Patented_So_Do_Not_Use() from an API if something's going to break by sending it and not getting the proper response back.

</comment><comment><USER5> Your seem to be misrepresenting the viewpoint you are responding to, confusing patents (which were not the issue with the APIs) with copyrights (which were.)

Also, as your link note, the UI patents are _design patents_ , which don't cover visual but not functional elements; an API is not within the scope of design patents.</comment>


Ask HN: How can I get better at bash? - <AUTHOR> I am interested mainly in bash helping me with the workflow of apps I run on the command line. <comment><USER2> As silly as it sounds, when I was a new Unix SysAdmin, I read the entirety of "man 1 bash", which includes all bash builtins. I found that it improved by bash-foo 100x simply by knowing about so many of the utilities. I also took some cliff notes for things that seemed generally useful.

I did it for an hour or so a night for a week or so.

That being said, a few of my personal favorites to memorize:

* Parameter expansion: [https://www.gnu.org/software/bash/manual/html_node/Shell-Par...](https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html)

* All of test(1) as you can use them in any if statement (/usr/bin/[ is a real command!): [https://linux.die.net/man/1/test](https://linux.die.net/man/1/test)

* Knowing most of the bash internal variables: [http://tldp.org/LDP/abs/html/internalvariables.html](http://tldp.org/LDP/abs/html/internalvariables.html)

* Keyboard shortcuts and how they are useful. A few example: CTRL-l (no need to ever use /usr/bin/clear), CTRL-k, CTRL-u, CTRL-e, CTRL-a, CTRL-w, CTRL-arrow left, CTRL-arrow right, CTRL-r (history reverse search with find as you type autocomplete)

The best way you can learn the shell is by using Linux as your primary desktop for at least a few months. You'll get very proficient very quickly by doing that.

<comment><USER3> Also CTRL-_ which is "undo whatever you just typed"

<comment><USER4> pressing CTRL-w a few times feels easier to me, less awkward key combination

<comment><USER5> CTRL-w just deletes a word at a time. CTRL-_ it appears doesn't just delete the whole line you just typed, it does undo of the thing you just typed... counting backspace as "one thing you just typed" \-- so it does some things you can't achieve with CTRL+w, you can even get back some text that you just erased.

I never knew this shortcut before. (I will probably never use it...)

</comment></comment></comment></comment><comment><USER6> Most of the responses here so far that do not include some sort of a guide are not the responses you're looking for (imho).

Mind your pipes and quotes. Guard your variables with braces. Do not export everything, test for and (try to) handle return codes and conditions and keep it simple (emphasis simple) but most of all just write it.

BASH (or Bourne) is ubiquitous when dealing with systems (vs programs). You don't need to be on the fashionable lang of the day by any measure. BASH, for most cases, will always be there, always ready and, in most cases, is the default human interface for deployed systems. As scripting languages go you don't need "better", you need dependability, zero dependencies with no requirement for modules or any other whizbangwoohoo plug-in. Language Fashionistas and personal preferences aside at least some level of fluency with BASH should be mandatory for anyone interfacing with a system.

<comment><USER7> [https://www.google.com/search?q=whizbangwoohoo](https://www.google.com/search?q=whizbangwoohoo)

<comment><USER8> Google Whack!

<comment><USER9> Technically no. A Googlewhack requires 2 dictionary words. Dave Gorman won't be visiting us.

</comment></comment></comment></comment><comment><USER10> I have written a simple tool called mann ([https://github.com/soheilpro/mann](https://github.com/soheilpro/mann)) to help me remember little things that I learn when working in Bash/Zsh.

Basically, every time I learn something useful about a command, I add it to its mann page and then whenever I need it in the future, I simply run 'mann <command>' to find it.

Here's the current output of my 'mann sed', for example:

      # Add char to beginning of each line
      sed 's/^/#/'

      # Replace with newline
      sed 's/<oldvalue>/\'$'\n''/g'

      # Replace newline
      sed -e ':a' -e 'N' -e '$!ba' -e 's/\n/<newvalue>/g'

      # Plus sign
      sed -E 's/foo+/bar'

      # Digit
      sed -E 's/[[:digit:]]/bar'

      # Inplace
      sed -i'.bak' -e <pattern> <file>

<comment><USER11> This looks great. I've always kept those types of little snippets in the README of my dotfiles repo - and always keep a printed out copy on my desk. But this seems way more practical.

[https://github.com/ben174/dotfiles/blob/master/README.md](https://github.com/ben174/dotfiles/blob/master/README.md)

</comment></comment><comment><USER12> If you're not already familiar with it, I would suggest learning about the basic Unix process model -- fork, execve, wait, open, pipe, dup2 and friends.

Bash is essentially a DSL for these. A lot of the weirdness you see in the language is due to these abstractions leaking through. For example:

* Quoting is building execve's argv parameter. It's hard to quote correctly if you don't know what exactly you're working towards.

* Redirections are opening and copying file descriptors. It explains their scope, order and nesting behavior.

* Variables are modifying and passing the environment, and their weird scope is due to forks imposed by the process model.

Once you know how you can do whatever you want in C through the basic syscalls, Bash is an extremely efficient and far less surprising shortcut to do it.

<comment><USER13> > Quoting is building execve's argv parameter.

can you expand on this? does this elucidate, e.g., variable substitution and the difference between single- and double-quotes? or does it just help demonstrate when you need quotes for an argument that may contain whitespace?

<comment><USER12> The behavior of quotes can and should be described in terms of how they affect the words they expand to (i.e. the argv you build), so yes, it clarifies all this.

For example, all the various wrong ways of quoting var="My File.txt" or otherwise incorrectly using such a name will result in variations on a wrong argument list:

      execlp("cat", "$var", NULL);            // cat '$var'
      execlp("cat", "My", "File.txt", NULL);  // cat $var
      execlp("cat My File.txt", NULL);        // cmd="cat $var"; "$cmd"
      execlp("cat", "'My", "File.txt'", NULL);// cmd="cat '$var'"; $cmd
      execlp("cat", "My\\", "File.txt", NULL);// cmd="cat My\ File.txt"; $cmd
      execlp("cat", "'My File.txt'", NULL);   // var="'$var'"; cat "$var"
      execlp("cat", "\"$var\"", NULL);        // arg='"$var"'; cat $arg

Meanwhile, all the correct ones result in the same, correct argv:

      execlp("cat", "My File.txt", NULL);  // cat "$var"
      execlp("cat", "My File.txt", NULL);  // cat 'My File.txt'
      execlp("cat", "My File.txt", NULL);  // cat "My File.txt"
      execlp("cat", "My File.txt", NULL);  // cat My\ File.txt
      execlp("cat", "My File.txt", NULL);  // cmd=("cat" "$var"); "${cmd[@]}"
      execlp("cat", "My File.txt", NULL);  // arg="'My File.txt'"; eval "cat $arg"

If you don't know which argument list you're aiming for, you basically have to go by guesswork and superstitions.

</comment></comment></comment><comment><USER14> Not the first thing to look for, but I've found ShellCheck[1] to be pretty helpful when it comes to correcting typical mistakes.

[1]: [https://github.com/koalaman/shellcheck](https://github.com/koalaman/shellcheck)

<comment><USER15> Seconded. Running ShellCheck integrated with your editor (easy with vim/Syntastic) is really great way to improve your bash skills.

It will highlight common mistakes, and their wiki explains each one detail and how you should use an alternate, better implementation.

</comment></comment><comment><USER16> Read Greg's wiki - BashGuide: [http://mywiki.wooledge.org/BashGuide](http://mywiki.wooledge.org/BashGuide)

<comment><USER17> Yeah, reading his BashFAQ helped me progress a lot: [http://mywiki.wooledge.org/BashFAQ](http://mywiki.wooledge.org/BashFAQ)

</comment></comment><comment><USER18> Besides the obvious answers of just reading the manual, looking up howtos, and stackoverflow I can recommend some habits that might increase your uptake of bash.

1\. If you are not running a unix as your default OS switch to one (ie Linux or Mac).

2\. Create a bin (~/bin) directory in your home directory of all your shells scripts and source control it. Any script you ever write put in that directory. Even if its not bash (ie python, perl). I find that it is critical to look at how you did things previously to help you learn as well as it saves time.

3\. Any command that is complicated one liner that you create or see on the internet... create script and put in the bin directory mentioned above.

4\. Optimize your personal bin directory and review frequently.

5\. If you run Linux build your system from scratch (ie read Linux from scratch).

6\. Bonus to the above: Automate the creation of your personal system through Packer and Bash!

7\. Find where things are not automated.

8\. Bash is more than just the shell. A knowledge of GNU coreutils as well as tmux/screen is worthwhile and highly recommended.

9\. Learn the readline shortcuts. Particularly "ctrl-r".

<comment><USER19> Little late here but do you have any links for #6?

I've not been able to find anything good on setting up a dev machine image with packer.

</comment></comment><comment><USER20> How about you don't? Bash as scripting language is rather mediocre.

Anything that is not simple in bash gets hard to read and debug and probably is wrong on some subtle levels.

I have a rule of thumb that any shell script that grows beyond a screenful of lines gets redone in a proper scripting language.

<comment><USER21> Bash as a scripting language is actually pretty amazing. It gives you everything you need to perform some quick-and-dirty tasks with minimal overhead. If you need only work on sequential data, files and processes, it's a perfect match.

It's not a full-fledged programming language by any stretch of the imagination (lacking structures more complex than associative arrays), but it's damn good for scripts of all sorts.

As an example, I've reimplemented a subset of Ansible (a command able to send "modules" on multiple machines via SSH and capturing+caching their output for subsequent queries) in ~150 lines of Bash. Considering that the size of Ansible, written in the more proper Python, is ~15000 LOC, I'd say Python is the much lesser scripting language.

Edit: to answer the OP's question, the documentation I've found most helpful to learn Bash is the one present on the Linux Documentation Project, with the page for arrays deserving special mention : [http://tldp.org/LDP/abs/html/arrays.html](http://tldp.org/LDP/abs/html/arrays.html). I spent a lot of time reading the manual before stumbling upon that documentation, and none of it really clicked until I had a few examples before my eyes.

<comment><USER22> Typically a program like Ansible will have the majority of its use cases implemented in a minority of its code, while the rest of the code will be there to support special cases, edge cases, rare use cases, etc. So that contributes to the disparity in size.

</comment></comment></comment><comment><USER23> Figure out a problem and try solving it in bash - bash for beginners guide on tldp site can get you started. You get better as you use it.

[http://www.tldp.org/LDP/Bash-Beginners- Guide/html/](http://www.tldp.org/LDP/Bash-Beginners-Guide/html/)

EDIT : Additional links -

Advanced - [http://tldp.org/LDP/abs/html/](http://tldp.org/LDP/abs/html/)

Bash programming - [http://tldp.org/HOWTO/Bash-Prog-Intro- HOWTO.html](http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html)

<comment><USER24> ABSG is always my answer to how to learn shell

<comment><USER25> Just googled ABSG and all I got was 'Adult Bible Study Guide'

<comment><USER26> To really understand Bash, one's soul must be in tune with God.

</comment></comment></comment></comment><comment><USER27> Train yourself to take the 20 minutes required to learn to "do it the right way" every time you need to. Its so easy not to bother because you are busy but in the long run you will save time.

<comment><USER28> I think this is the right answer, assuming OP actually wants to get better at bash and not route around his original question by learning stuff that isn't bash.

I use bash/shell scripts frequently and have many running 'in production' as cron jobs th at run various jobs or manipulate data for other jobs to run on.

One thing I really like about pure shell is that it's extremely portable and transparent about what it's doing.

I still have to re-learn control structures almost everytime I write a new script, I don't try and memorize [[]] vs [] and all the weird ways equality can work, I just google each time and answers are always on top (once you know what you're looking for).

<comment><USER29> I couldn't begin to say how many times I've typed "help test". It's a lot. I usually get the answer I'm looking for, when it comes to conditionals.

<comment><USER28> TIL. even faster than the google

</comment></comment></comment></comment><comment><USER30> Read the manual front to back and install shellcheck. Doing both things has paid off for me a thousand times over. The rest is practice. Complete the bash exercises on Hackerrank. Bash is fantastic in it's domain but it does require serious study in my experience

<comment><USER31> I can second the shellcheck recommendation. Shellcheck makes great recommendations, and every suggestion has a corresponding code you can google to get to a detailed explanation of why that is considered a warning or error. Hell, even if I just considered the times I forgot to put quotes around a variable and got warned by shellcheck I would be happy that I use it.

<comment><USER32> [http://www.shellcheck.net/](http://www.shellcheck.net/)

[https://packagecontrol.io/packages/SublimeLinter- shellcheck](https://packagecontrol.io/packages/SublimeLinter-shellcheck)

</comment></comment></comment><comment><USER33> The Tcl programming language is what shell scripting should be, basically. It is not just a language with all the features you need, it has explicit Unix shell alike scripting capabilities and strong DSL abilities. An example two- liner:

        set files [glob /etc/*.conf]
        foreach f $files {file lstat $f file_info; puts "$f: $file_info(size)"}

        /etc/asl.conf: 1051
        /etc/autofs.conf: 1935
        /etc/dnsextd.conf: 2378
        ... and so forth ...

Also there is an `exec` command that supports pipes, redirections, and so forth:

        set result [exec cat /etc/passwd | grep Directory]

The pipe has no special meaning in Tcl, but because of its DSL capabilities you can do things like that. Exec is a DSL basically.

</comment><comment><USER34> For scripting, I recommend the rc shell from plan9, which is the one I use for my shell scripts. It is only when I want to share a script with other people that I consider using /bin/sh, and even then more often than not I've gone for rc.

I invite you to read about it: [http://doc.cat-v.org/plan_9/4th_edition/papers/rc](http://doc.cat-v.org/plan_9/4th_edition/papers/rc).

I find the control structures simpler and more elegant, and overall its design feels more consistent. For example, consider an if statement in bash:

      if [ condition ]; then
        ...
      else
        ...
      fi

And now in rc:

      if (condition) {
        ...
      } else {
        ...
      }

Or a case statement in bash:

      case $1 in
        "bar")
          ... ;;
        "baz")
          ... ;;
      esac

And expressed in rc:

      switch ($1) {
        case "bar"
          ...
        case "baz"
          ...
      }

In the past, I've used it as my shell too, but now I use it only for scripting. I think you can install it in most platforms.

</comment><comment><USER35> I recommend starting w/ Gary Bernhardt's excellent "Tar Pipe" blog post.

[https://web.archive.org/web/20161227222637/http://blog.extra...](https://web.archive.org/web/20161227222637/http://blog.extracheese.org/2010/05/the- tar-pipe.html)

From there, move on to using the shell as your IDE. How? First, understand the Unix philosophy. I think Ted Dzubia describes this pretty well in his Taco Bell Programming blog posting:

[http://widgetsandshit.com/teddziuba/2010/10/taco-bell- progra...](http://widgetsandshit.com/teddziuba/2010/10/taco-bell- programming.html)

Great, so now you understand that there are a bunch of useful tools out there and you can string them together to do great things. Now you need to discover the tools themselves.

If you're a "read the dictionary" kind of person, go ahead and start off w/ the Gnu Coreutils documentation. [https://www.gnu.org/doc/doc.html](https://www.gnu.org/doc/doc.html)

However, if you're like me you'll learn fastest by watching other people work. In this case, I have to point back to Gary Bernhardt again. Specifically, his "Composing a Unix Command Line" screencast will open your eyes _wide_ and very quickly introduce you to a range of incredibly useful coreutils programs in the context of solving a very specific problem. This content is $29/mo, but I'd argue it's money well spent. [https://www.destroyallsoftware.com/screencasts/catalog/compo...](https://www.destroyallsoftware.com/screencasts/catalog/composing- a-unix-command-line)

</comment><comment><USER36> Flame war between bash/fish/zsh/powershell is almost meaningless to beginners, because the basic skills are common to all shells. (That said, you will love zsh once you use it)

I learned to use shell, about 7 years ago, by reading O'Reilly "Classic Shell Scripting". It is well written, and teach you something that you can hardly learn from google. But don't try to remember everything, especially those advanced string manipulation syntax, because one would usually use a scripting language such as ruby for advanced job.

<comment><USER37> > I learned to use shell, about 7 years ago, by reading O'Reilly "Classic > Shell Scripting".

I can second this recommendation. :)

</comment></comment><comment><USER38> Helping you how? If you actually have a problem you are trying to solve, then do just that. My experience with command line came from solving problems I had. Today I do a lot in the command line and I am learning new things all the time. However if I just wanted to get "better" at it, then I don't even know where to start because there is no clear goal.

<comment><USER23> Well said, it's an ongoing process and there is always something new to learn - some use case which we may not have come across. So, it's an ongoing process.

</comment></comment><comment><USER39> I wanted to get better at bash too, but instead I ended up getting everything[1] done at fish, which is cool, much better as a language, but no environment has fish pre-installed nowadays.

[1]: [https://github.com/fiatjaf/react-site](https://github.com/fiatjaf/react- site)

</comment><comment><USER40> I used to lean on python for much of my scripting needs, mainly because the more advanced bash syntax was pretty daunting. Getting better at bash has a trickle-down effect, especially in this container age. ENV var scoping + loops and various var expansion methods really made it click for me. Shelling out to various tasks (and grabbing the results) is effortless via bash scripts. With bash on windows now it's pretty much ubiquitous. My advice is to consider why the task at hand can't be done in bash, because often times it can, with much more portability.

<comment><USER41> In both my personal and professional life, I have the opposite conclusion. Bash is only for the simplest scripts and pipelines, and everything else (assuming you're going to use it more than once) gets written in Python or Go.

The Bash syntax is not daunting, or if it is that's never been the problem with Bash. The problem is that Bash or shell programming in general gives you a million ways to shoot yourself in the foot and maybe one or two obscure, funny-looking ways to do what you want. Like iterating over the files in a directory, for example. If you think that's easy in Bash you have either have a funny definition of easy or you're forgetting a few corner cases. Or getting the output from a program—did you know that $(my_prog) or `my_prog` modifies the program output?

For containers we do everything declaratively.

<comment><USER42> > Like iterating over the files in a directory, for example. If you think > that's easy in Bash you have either have a funny definition of easy

Maybe I'm overlooking something...but why wouldn't this work:

for file in $(ls); do {<looped command>}; done

<comment><USER43>
      $ mkdir "hi there"
      $ mkdir "how are you"
      $ ls -l
      total 8
      drwxr-xr-x 2 xxxxxxxx xxxx 4096 Jun 26 14:54 hi there
      drwxr-xr-x 2 xxxxxxxx xxxx 4096 Jun 26 14:54 how are you
      $ for f in $(ls); do echo $f; done
      hi
      there
      how
      are
      you

<comment><USER44> ls | while read file; do echo "$file"; done

... works better for the easy edge cases, but still probably has some issues. Personally I think klodolph called it; once you get into anything that has a few interesting edge cases bash becomes pretty unwieldy.

<comment><USER45> The easiest way is still: for file in *; do ...; done

This works fine with spaces and other strange characters, no need to come up with more complicated ways.

If you must use find, the correct way is really tricky and uses obscure bash features like settings IFS to the empty string to split on null bytes and process substitution so that the loop doesn't run in a subshell (which would prevent it from modifying variables in the current environment):

while IFS= read -r -d '' file; do ... done < <(find /tmp -type f -print0)

See [http://mywiki.wooledge.org/BashFAQ/020](http://mywiki.wooledge.org/BashFAQ/020)

<comment><USER44> I like that, I've never thought of or seen it, although it should've been intuitively obvious given how bash expansion works.

I think this demonstrates the point pretty well though - it takes a discussion among three of us before arriving at something that works moderately well, and we found four fairly different ways of doing it...

</comment></comment></comment></comment></comment></comment></comment><comment><USER46> From a 14+ year Linux/Unix admin:

Get a very brief reference book of every common UNIX command. Read all the commands, what they do, what options they take. Start using them.

Shells are most useful when they are used to tie together other programs. In order to do this, you have to know what all the command-line tools you have at your disposal are. Learn the tools, then start writing examples using them. Keep the examples and the docs somewhere to reference them later.

For quick reference, the command 'whatis' will give a blurb from the top of the command's man page. `whatis ls' "ls (1) - list directory contents". View many at once with "(cd /usr/bin; whatis * | grep -v noth)". Many often-used commands come in "util-linux" and "coreutils" packages. Read man pages completely when convenient.

It may also help to have a VM or desktop which has no GUI, where you will be forced to use the command-line. When I was starting out I used a desktop with no X server for months. You can get a lot more done than you think (and 'links -g' provides a graphical browser if you need images)

To learn more about Bash itself, you can look for server installation software packages made with Bash, or in the "init" tools distributed with big distros like RedHat, SuSE, etc before they used systemd. But it's better to get used to more shell-agnostic scripting using UNIX commands than it is to use Shell- specific language/syntax.

<comment><USER47> _" (and 'links -g' provides a graphical browser if you need images)"_

Without X presumably needs framebuffer or something?

<comment><USER46> It has a variety of drivers, such as for X, framebuffer, svgalib, OS/2 PMShell and AtheOS. It also bundles antialiased fonts.

</comment></comment></comment><comment><USER48> Don't listen to the guys who are saying not to learn bash. In the right circumstance bash is much better than any verbose python script.

I'd say learn the following topics:

pipe grep sed awk find

Once you feel comfortable using and combining these tools you should be able to find out the rest by yourself.

<comment><USER49> At the risk of being pedantic, grep sed awk and find are not bash, they are their own programs. You can run find from any shell, or without a shell at all.

</comment></comment><comment><USER50> I'm ok at bash, but I do not default to complicated bash scripts for my needs. I make little reusable tools. For example I have a tool aliased that makes it easy to apply quick ruby code. For example

echo "345.44

544.50" | rg "€#{l}: €#{(l.to_f * 3).to_i}"

Produces the following output:

€345.44: €1036

€544.50: €1633

Based on this code:

[https://gist.github.com/zachaysan/4a31386f944ed31a3f8a920c85...](https://gist.github.com/zachaysan/4a31386f944ed31a3f8a920c85bddbb9)

I find it's much faster to be productive like this than it is to try to do the same with ruby -e because I really only want to manipulate single incoming lines. I don't want to have to write the looping code or the code that sets variables or what have you.

Also, sometimes it gets confusing what tools are just bash functions or alias and which are scripts, so if you ever forget what a tools definition is just type:

type toolname

As for actually answering your question, look at your friend's dotfiles on their github account to learn which tools and tricks they use and when you don't know how something works ask them questions. People will usually point you in the right direction.

<comment><USER43> Any particular reason you don't use `ruby -p`? Looks like it's doing pretty much the same thing.

</comment></comment><comment><USER51> One thing I would say is first check that you are running the latest version! There has been a lot of development to bash over the years. If you feel like customizing things a lot I'd check out zsh and [http://ohmyz.sh/](http://ohmyz.sh/). It has a lot compatible with bash with (IMO) some saner scripting support.

Aliases are something I use a lot - it's very basic but just having "big long command with options" aliases to something easy to remember makes it much more likely I will not make mistakes, can repeat it easily in loops.

Another thing that complements using bash effectively are using other applications config files. As soon as I have a new host to interact with I add it to my ssh.config file - then any scripting I need to do I don't need to deal with any special files. Other files like ~/.netrc or ~/.pgpass make my shell sessions that much more productive. For some reason many people don't bother ever updating these and rely on the shell history to do anything more than once.

CommandlineFu ([http://www.commandlinefu.com/commands/browse](http://www.commandlinefu.com/commands/browse)) has some nice one liners and there's often some gems on ServerFault ([https://serverfault.com/questions/tagged/bash](https://serverfault.com/questions/tagged/bash)) - just browsing those for topics matching your workflow can be very fruitful.

I've found the more I do anything at the shell of any complexity I end up writing a small python command line client to do any heavy lifting. Argparse ([https://docs.python.org/3/library/argparse.html](https://docs.python.org/3/library/argparse.html)) makes this trivially easy and then I can use regular shell "glue" to combine a few commands together.

</comment><comment><USER52> In addition to what others said, I can recommend just reading through the manpage once (probably in multiple sittings). Even if you don't remember the exact syntax, you will have an idea what bash _can_ do, and know enough of the jargon to find it again in the manpage when you need it. For example, when I need to replace a substring, I used to do

      FOO="Hello World"
      ...
      BAR="$(echo "$FOO" | sed "s/World/Hacker News/")"

until I remembered that bash can do string replacement by itself. A quick search for "pattern" and "substitute" in the manpage turned up the right syntax,

      BAR="${FOO/World/Hacker News}"

<comment><USER53> I would also recommend to read Single Unix Specification on shell syntax, and then avoid bashisms whenever possible. Bash had a history of subtly changing its behaviour in these, which leads to scripts getting suddenly broken without any modification on system update.

<comment><USER54> Could you give some examples? [http://wiki.bash- hackers.org/scripting/bashchanges](http://wiki.bash- hackers.org/scripting/bashchanges) and [http://wiki.bash- hackers.org/scripting/obsolete](http://wiki.bash- hackers.org/scripting/obsolete) aren't particularly enlightening.

<comment><USER53> What I was hit with were subtle changes to how [[ ]] worked, along the lines of implicit anchoring in pattern in previous version not taking place in succeeding version. It took quite a while to debug what became a logic error.

After that I started avoiding bashisms in my scripts, especially that they usually provide very little benefit at the cost of gambling against breaking silently on a barely related update.

Nowadays it's also worth noting that #!/bin/sh often (Debian derivatives) points to something that is not Bash, and people writing in shell/Bash usually don't understand the difference.

</comment></comment></comment></comment><comment><USER55> Forget the Bash man page (just temporarily, that is) and read this:

[http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3...](http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html)

The POSIX specification of the Shell Command Language.

Also, don't overlook that there is a GNU Info manual for Bash, not just the manual page:

[https://www.gnu.org/software/bash/manual/html_node/index.htm...](https://www.gnu.org/software/bash/manual/html_node/index.html)

</comment><comment><USER56> I was about to post:

> Add, "#! /usr/bin/python" to the top of your scripts, it will make your life > easier.

However, after reading the rest of the thread, it seems Python and similar langs are not actually great for the kind of things people use Bash for, and Perl is the way to go!

Great, another language to learn...

edit, re: python:

fiatjaf suggested xon.sh:

"shell language and command prompt [..] based on Python, with additional syntax added that makes calling subprocess commands, manipulating the environment, and dealing with the file system easy.

[http://xon.sh/tutorial](http://xon.sh/tutorial)

</comment><comment><USER57> I learned bash primarily for practical reasons (ie. navigating in Linux, parsing files, searching for text) and nothing more. Definitely not from a DevOps or SysAdmin point of view as I'm sure fits the background of many commenters in this thread.

If your use case is pragmatic in nature, I would recommend my post on the topic: [http://alexpetralia.com/posts/2017/6/26/learning-linux- bash-...](http://alexpetralia.com/posts/2017/6/26/learning-linux-bash-to-get- things-done)

</comment><comment><USER58> Take a look at this tutorial [1]. It will teach you some shortcuts, a bit of shell expansion, and help you set sane defaults in bash. One that I'm particular fond is to set

      "\e[A": history-search-backward
      "\e[B": history-search-forward

in your ~/.inputrc. So, if you are typing a command which begins with "git", it will only search in history for commands that start with git (instead of returning all commands that may include the string 'git' like Ctrl+r). Having trouble trying to remember that option you passed to `git log`? Just type in `git log` and press the up arrow to find your last usages.

I think it is also helpful to learn Emacs or vim keybindings. I use Emacs keybindings in bash a lot (enabled by default). I have summarized the ones that I used more often in a previous comment [2].

[1]: [https://www.ukuug.org/events/linux2003/papers/bash_tips/](https://www.ukuug.org/events/linux2003/papers/bash_tips/)

[2]: [https://news.ycombinator.com/item?id=13404262](https://news.ycombinator.com/item?id=13404262)

</comment><comment><USER59> Just like how you learn any other programming language: use it to solve your problems.

Anyway, here's a few steps that I would recommend:

1\. Go through [http://tldp.org/LDP/abs/html/](http://tldp.org/LDP/abs/html/) and [http://www.tldp.org/LDP/Bash-Beginners- Guide/html/](http://www.tldp.org/LDP/Bash-Beginners-Guide/html/) , or at least go through the table of contents so that you have a feeling of what bash is capable of. A few important things are: if, while, for, switch, functions, string manipulation, pipe, subshell, command substitution

2\. Understand the execution model. Variables in subshell cannot be accessed from the parent shell, this is a common mistake

3\. Learn to avoid common pitfalls. I always recommend my colleagues to always quote the variables in double quote, always use "$@" instead of "$*", always use double square bracket instead of single square bracket for testing, use echo to pass return value from functions instead of assigning to global variable

4\. Learn awk, sed, grep. Bash can be quite limiting when it comes to data processing and these tools can be quite powerful. You can use bash to glue different filters together at a higher level.

Bash is a fantastic language and there are quite a lot of things that can be much more quickly in bash than in other "proper" languages. A lot of people says that it's too difficult to maintain a shell script beyond a "critical mass" but I believe that if you follow good practices and write modular codes, shell scripts can be very manageable.

</comment><comment><USER60> If you're interested in getting better at the terminal, I recommend you learn how to customize it. it'll really help you learn by doing and figuring out what it is you want to learn how to do first.

It's what worked for me, though. There are also some workflow ideas that have really helped a lot. Autocompletion and being about to look through your history for commands is super helpful too.

``` cat $HOME/.bash_history | grep -E 'command|argument' ```

[https://github.com/zsh-users/zsh-autosuggestions](https://github.com/zsh- users/zsh-autosuggestions)

I just finished a guid on my site about my terminal setup. I hope to read yours once you've customized the pixels out of it.

Aside from things to get your interested in the internals of your shell via bash scripting, you should also consider writing more shell scripts specifically around your workflows. I keep mine in a .files repo on GitHub. Take a look at the install script. It took me over a year to get really fluent in bash scripting enough to make it possible to get better and better at it.

Good luck on your journey!

</comment><comment><USER61> Bookmark the following url and come back to it as often as you need:

[http://tldp.org/LDP/abs/html/](http://tldp.org/LDP/abs/html/)

Also this one to learn some cool tricks:

[http://www.commandlinefu.com/commands/browse](http://www.commandlinefu.com/commands/browse)

<comment><USER62> Yes for ABSG, especially the manipulating strings and process substitution.

That and shellcheck(+syntastic if you use vim) ramps up the skill level quite fast.

</comment></comment><comment><USER63> First, if your bash script grows beyond about ten lines, it's time to consider rewriting it in a cleaner language. Python's a common one. I used to use Haskell for that kind of scripting as well, which was astonishingly good at it.

Here's my study suggestion:

0\. Learn to use variable interpolation and backticks.

1\. if blocks and the [ built-in function. Go read about the grammar and look at the flags that [ takes. Memorize the most common couple (file exists, is a directory), and know how to look up the others when needed. Find examples of variable interpolation tricks needed to make this function.

2\. for and while blocks. Learn the grammer. for is mostly useful with `seq ...` or a file glob.

3\. Learn some of the options to make bash fail early and loudly like pipefail.

4\. Most of the power of bash is in the programs you call, and they aren't always the same ones you use interactively. Other folks have mentioned some of these. find, xargs, wait...

<comment><USER64> > if your bash script grows beyond about ten lines, it's time to consider > rewriting it in a cleaner language

Just because you don't feel comfortable writing long scripts doesn't mean you should discourage others.

There are many many justifications for sticking to shell, for example if you need to write a portable installer that works across every UNIX variation.

<comment><USER63> > Just because you don't feel comfortable writing long scripts doesn't mean > you should discourage others.

And deprive them of the hard learned lessons from decades of experience?

> There are many many justifications for sticking to shell, for example if you > need to write a portable installer that works across every UNIX variation.

Do you mean every Linux variation? Because trying to write shell portable from old HP-UX to Darwin is an exercise in insanity.

</comment></comment></comment><comment><USER65> Set your default shell to bash, and every time something annoys you, look up how to fix it (stack overflow is basically complete at this point, if you know what to search for) and put it in your dotfiles.

I used to rely on fish, but after a couple of bugs (either in fish or my fingers, not sure) I switched back to bash at my job (on a Linux desktop).

After a few months I had built up a good set of aliases and functions (my most used function is rgrep, see below) and was confidently ^R reverse searching and so on. These things are great because as you jump systems (e.g. to macOS) they continue to work.

TLDR: Practise practise practise!

        # the rgrep function

        # recursive text file search from the current directory.
        function rgrep {
            if [ -z "$1" ];
            then
                echo "please supply a search string."
                return 1
            fi
            grep -rn $1 .
        }

<comment><USER66> I can recommend tools called Silver Searcher and/or RipGrep for text searching.

      https://github.com/ggreer/the_silver_searcher
      https://github.com/BurntSushi/ripgrep

</comment></comment><comment><USER67> As an alternative, you could also look into PowerShell. it's open source and cross platform. I use it because it's really powerful on Windows.

In any programming language, you learn by practice. Given that your shell does so much, that's the easiest place to find tasks to practice on. I have been leaning on my shell scripts to do a lot of automation. The list is long and I just pick something from that list to work on for most days.

If you don't have system automation that you want to work on, then you probably have a lot of personal data that you can work with. I have scripts setup to manipulate data exports from the various services I consume and then remix that data in my own database. My shell scripts can get the data, operate on it and then shove it into a DB. Then I'll use something else to display that data.

</comment><comment><USER68> [https://www.gnu.org/software/bash/manual/bash.txt](https://www.gnu.org/software/bash/manual/bash.txt)

I like bash for the same reason I like emacs, in that no matter what the environment is like, I can usually count on my bash scripts to work. I keep them in emacs org-mode files where I store them in src code blocks. I can tangle multiple code blocks into single executable scripts to different directories. Check out org-mode babel, tangeling, and noweb. Keeping all my bash code in a single file solves my issue with having to dig for that one script I wrote that one time because I forgot how to do this one thing ...

If you aren't running Linux on your desktop yet, consider it. Full immersion is a fast way to learn.

</comment><comment><USER69> Learn to move around efficiently: End of Line, Beginning of Line, Move by word so you aren't just abusing your keyboard.

Knowing how to reverse search (Ctrl-R) and run last command !vim or !curl to rerun last instance of vim or curl command with args so you don't have to search every time.

</comment><comment><USER70> I wrote a thing for this! People should read it! Focus is on usage, not scripting.

What Kai Thinks Every Developer Should Know About the Shell

[https://github.com/tenebrousedge/shell_guide](https://github.com/tenebrousedge/shell_guide)

</comment><comment><USER71> This script can be useful to save man pages (not just the bash man page, any man page) as text - removing all the control characters which are used for printing with formatting (bold, etc.):

m, a Unix shell utility to save cleaned-up man pages as text:

[https://jugad2.blogspot.in/2017/03/m-unix-shell-utility- to-s...](https://jugad2.blogspot.in/2017/03/m-unix-shell-utility-to-save- cleaned-up.html)

I've been using it from earlier Unix versions, where these formatted man pages (nroff/troff-formatted) were more of an issue. Also works if you want to open the text form of the man page in vi or vim, for reading, searching, etc.

</comment><comment><USER72> 1\. Use it.

2\. Conceive of use-cases you can't already solve, and see if you can find a way to do them using Bash.

3\. Consider that perhaps Bash isn't the best tool for every job. (It most certainly isn't, though you can abuse it frightfully.)

4\. Books. Jerry Peek's guides are getting rather dated, but they're still a good introduction.

5\. Read the manpage. Frequently. Find some part of it that doesn't make sense, or that you haven't played with before, and play with it. Shell substitutions, readline editing, parameter substitution, shell functions, math, list expansions, loops, tests, are all high-payoff areas.

6\. Take a hard look at zsh, which does a great deal Bash doesn't.

</comment><comment><USER73> Do some puzzles(wargames). For example: [http://overthewire.org/wargames/](http://overthewire.org/wargames/)

It will make you search for several special use cases and will give you some experience with the command line. Basically, you SSH into a box, solve a problem and the solution for that problem is the password for the next SSH connection for the next problem.

This one is for beginners: [http://overthewire.org/wargames/bandit/](http://overthewire.org/wargames/bandit/)

</comment><comment><USER74> This doesn't work for everyone, but if you find allow yourself time, trying to solve specific problems you face (asking: could I automate this? Could this be simpler?) is a great way to get better - and how I learnt my way through bash.

I recently released [https://terminal.training](https://terminal.training) (paid course for 4 hours) which is just for this kind of question, but I've also started a free mini email course (same URL) that tries to share some of the CLI shortcuts I've come to rely on over the years.

</comment><comment><USER75> Depending on your level, there's [https://terminal.training/](https://terminal.training/) (by the same chap who runs jsbin).

</comment><comment><USER76> In my opinion the most important thing to know about shell scripting is when not to use it. The shell is very powerful but also clumsy for tasks that exceed the basics.

</comment><comment><USER77> A while back, I wrote a quick Bash guide called "Adventures in Data Science with Bash" ([https://gumroad.com/l/datascience](https://gumroad.com/l/datascience)).

It covers basic Bash commands (head, less, grep, cut, sort, uniq, curl, awk, join), but also pipes, for loops, variables, arrays, and command substitution.

</comment><comment><USER78> Work through the Advanced Bash Scripting Guide ([http://freecode.com/projects/advancedbashscriptingguide/](http://freecode.com/projects/advancedbashscriptingguide/)). It's a great resource and is one that I turn to when I need to remind myself of how to do something.

</comment><comment><USER26> The best I can really recommend is practice. A lot of "bash" skill comes not from bash itself, but rather from the tools around it.

If you're not already comfortable with input/output redirection (including pipes, as well as reading from / writing to files via <file / >file, respectively), then that's where I'd start.

</comment><comment><USER79> The shell language itself is pretty simple and featureless. It relies on the system utilities for most things so once you know the basics of how the shell works you should probably focus on learning those rather than bash. Also I find that when it comes to interactive use having good key bindings and some nice aliases makes a lot of difference.

</comment><comment><USER80> Use it daily. Use it instead of your graphical file explorer options.

Everything will take longer but imho it's the only way to get better.

</comment><comment><USER81> I made a search engine to show the best learning paths for learning any topics.

Here is the path for learning bash : [https://learn-anything.xyz/operating- systems/unix/shells/bas...](https://learn-anything.xyz/operating- systems/unix/shells/bash)

</comment><comment><USER82> This article posted here last year has some excellent tips in advancing your bash-fu, many have been mentioned here but has some extras as well:

[http://samrowe.com/wordpress/advancing-in-the-bash- shell](http://samrowe.com/wordpress/advancing-in-the-bash-shell)

</comment><comment><USER83> GNU BASH is a branch of the Bourne-shell family.

Korn shell is a much more complete and capable variant of Bourne. BASH partially implemented many Korn features, but not everything.

The standard reference is the Korn and Bolsky book (2nd edition). I'm not aware of any free/online resources that are profoundly good.

Korn is the very best for scripting.

</comment><comment><USER84> I'm not sure if this answers your question since I'm not sure what the implications of your workflow are, but I got a huge jump in productivity with Oh My Zsh. It has a bunch of features like tab completing past commands, it includes various shortcuts, etc. It's also compatible with bash.

</comment><comment><USER66> Its considered kind of a security risk, but I like to save ALL of my commands: (put this in .bashrc)

      export PROMPT_COMMAND='echo "$(history 1)" >> $HOME/.basheternalhistory'

Now you can search it later for arcane commands you've forgotten how to use.

</comment><comment><USER85> I recommend also learning a different shell's quirks and syntax. I started using fish a couple years ago, but I still have to write any 'production' scripts in bash. Learning fish cleared up lots of misunderstandings I had with bash and has made my bash much improved.

</comment><comment><USER86> I found this useful for getting deeper with using bash: "Pro Bash Programming : Scripting the GNU/Linux Shell, Second Edition." It is kind of a brain dump type of book but it called out a bunch of little things I had missed in looking at other information sources.

</comment><comment><USER87> 1) Force yourself to do as much as possible from command-line 2) When you Google for help and find a solution, keep Googling until you understand what you're doing

That worked for me. You could also read the man pages, but step #1 is crucial regardless.

</comment><comment><USER88> If you like learning by doing, play along with this:

[https://web.stanford.edu/class/cs124/kwc-unix-for- poets.pdf](https://web.stanford.edu/class/cs124/kwc-unix-for-poets.pdf)

(text analysis in bash)

</comment><comment><USER89> Check out ShellJS if you want to build scripts. For me at least it made things a lot less archaic: [https://github.com/shelljs/shelljs](https://github.com/shelljs/shelljs)

</comment><comment><USER90> Anytime I'm stuck with a script I usually end up on [https://bash.cyberciti.biz](https://bash.cyberciti.biz)

Vivek (founder) has been writing these tutorials for 17+ years, he knows his stuff.

</comment><comment><USER91> This covers 90% of bash: Learn Enough Command Line to Be Dangerous [https://www.learnenough.com/command-line- tutorial](https://www.learnenough.com/command-line-tutorial)

</comment><comment><USER92> I have a couple of resources for you:

[http://www.commandlinefu.com](http://www.commandlinefu.com)

[http://www.shell-fu.org](http://www.shell-fu.org)

</comment><comment><USER93> Bash has tons of quirks, but as others said, reading man bash helps quite a bit.

There is also this great resource: [http://wiki.bash- hackers.org](http://wiki.bash-hackers.org)

</comment><comment><USER94> Understand and utilize functions in your scripts.

If there is one thing I wish I had understood sooner, that would be it.

Top to bottom programmatic flow is one thing. Conditional execution and branching are on another level.

</comment><comment><USER95> One of my most common uses for shell scripts is writing completion functions for my aliases and custom commands. Hitting tab for a list of all options for a command is a huge timesaver.

</comment><comment><USER96> I really enjoyed [http://guide.bash.academy/](http://guide.bash.academy/) but it's not completed unfortunately.

</comment><comment><USER97> Pick up a copy of UNIX Shell Programming by Stephen Kochan. Very approachable and lots of good practical examples. Augment it with 'man bash' and Googling.

</comment><comment><USER98> Help develop and test this: [https://github.com/exercism/bash](https://github.com/exercism/bash)

</comment><comment><USER99> If its really about helping you with the command line then use fish.

If you need to automate something use your favorite programming language.

</comment><comment><USER100> man bash. read, digest, apply, repeat. you can also look at existing scripts, figure out what they do, why, make copy, alter, see the changes in behavior. there are also books on bash.

larger point: how do you learn more about X? or get better at doing X? figure that general pattern out and you can re-apply it for anything, not just bash.

</comment><comment><USER101> Give up? Seriously.

I used to force myself to do all of my ad-hoc scripting in bash, but I got sick of the clunky way of parsing arguments, dealing with arrays, looping over data objects, etc.

I got pretty good at it, but at some point I decided just to stick to a language I knew well (R) to string together various pipelines and construct commands. Any high-level language would work, though. I'm much more productive now.

</comment><comment><USER102> learn about how return from functions and echo behaves, this often bites many.

learn from this wiki that has many tutorials and good examples [http://wiki.bash-hackers.org/bash4](http://wiki.bash-hackers.org/bash4)

</comment><comment><USER103> Write and distribute tutorials targeting a wide audience with varied amounts of experience.

</comment><comment><USER104> hackerrank has various challenges in bash : [https://www.hackerrank.com/domains/shell/bash](https://www.hackerrank.com/domains/shell/bash)

</comment><comment><USER105> Have you read the manual?

</comment><comment><USER106> $ help fc

Using ${EDITOR} to build command lines is awesome. 'nuf said.

</comment><comment><USER107> Can't wait to see this thread commented on n-gate.

</comment><comment><USER108> among other things make sure you know how to use ! and ^ -- they will save you tons of time compared to searching or editing

</comment><comment><USER109> As you're focused on the command line, I won't mention things I generally use in shell scripts like compound commands (if, for, while) or shell parameters. I will also skip things I don't often use.

First, there is moving around in bash - the arrow keys, or backspace/delete to remove a character, or ^A to go to line start, or ^R to search command history, or tab to complete a command. ^L clears the screen, although from habit I still type clear.

I use shell/bash builtins cd, and pwd often enough. Sometimes export, umask, exit, ulimit -a, echo.

I use shell variables like PS1, HOME, and PATH. I set them in $HOME/.bashrc, which sometimes references files like $HOME/.bash_aliases. I often set a larger than default history file size. I use ~ tilde expansion as an abbreviation for $HOME. For long commands I type regularly, I put an alias in the run control (or run control delegated) file.

I use job control commands like bg, fg, jobs and kill. You should know how bash job control complements and diverges from the system process commands. & starts a process as a background process, and preceding it from nohup tells it to ignore hangup signals.

You should know how single quotes work, and escape characters for them if they are needed.

Then there are pipes (| - "pipelines"), and redirecting of stdin, stdout, and stderr. I use this a lot. Also redirecting or appending output to a file (>, >>). I don't use tee often but sometimes do.

Then there are commands used with the shell a lot. Such as parallel, or xargs.

Also nice which modifies process scheduling.

Script, or typescript, keeps a log of your shell session.

Screen allows for multiple shell sessions. Useful on remote hosts especially (tmux is an alternative).

Then there are the standard file and directory commands I often use like pwd, cd, ls, mv, cp, df, chmod, du, file, find, locate, mkdir, touch, rm, which, and wc.

I manipulate these with commands like awk, sed, tr, grep, egrep, cat, head, tail, diff, and less.

I edit with vim or emacs -nw.

Command like htop, ps, w, uptime and kill let me deal with system processes.

Then there are just handy commands like bc or cal if I need to do some simple addition or see which day of the week the first of the month is.

Man shows you manual pages for various commands. "man command" will show the manual page. For a command like kill, the default will show the command kill - "man kill" which specifically is "man 1 kill". But "man 2 kill" would show the kill system call. You can see what these different manual sections are with "man man" \- 1 is executable programs, 2 is system calls etc.

All of it is a process. I mentioned awk. It is one of the commands handy to use with the shell. I have seen entire programs written in awk. Some parts of awk I can use from memory, some I use occasionally and have to look up the flags to refresh my memory, some parts I have never used at all. As time goes on you pick up more and more as you need it.

</comment><comment><USER110> Some suggestions:

Direct your focus to plain Bourne sh as much as possible, moving on only after you understand what enhancements over vanilla sh Korn or Bourne-Again actually offer.

Pick up Manis, Schaffer, and Jorgensen's "UNIX Relational Database Management" and work through the examples to get a feel for the philosophy behind large, complex applications written in shell.

Join a Unix community (sdf.org) and try to do useful things with shell (e.g. cron-schedule stock quote e-mail notifications via shell scripts, etc).

</comment><comment><USER111> ctrl-r is my favourite.</comment>


Euler's identity encoded in a crop circle - <AUTHOR> http://www.independent.co.uk/news/uk/this-britain/crop-circle-season-arrives-with-a-mathematical-message-1982647.html

<comment><USER2> > Nobody knows for sure how crop circles are made.

Maybe this guy does. <http://news.bbc.co.uk/2/hi/uk_news/2191565.stm>

These two, as well: <http://en.wikipedia.org/wiki/Crop_circle#Bower_and_Chorley>

edit: and anyone who reads this: <http://www.wikihow.com/Make-a-Crop-Circle>

</comment><comment><USER3> More insightful analysis: <http://www.cropcircleconnector.com/2010/wilton/comments.html>

Someone must be playing joke on human brain ;-)</comment>


Redditor gives detailed breakdown of how Zuckerberg is linked to the olig - <AUTHOR> https://www.reddit.com/r/bestof/comments/85qvt7/redditor_gives_a_long_and_detailed_breakdown_of <comment><USER2> And the conspiracy theories start...

Mmmm, I wonder if the aliens dropped him off during one of their UFO flights?</comment>


Vfork considered dangerous - <AUTHOR> http://ewontfix.com/7/

<comment><USER2> This particular article beats an already dead horse, but it does it pretty well. Better than that: the rest of the blog containing the article is pretty darn good. Give it a read.</comment>


Safari users win right to sue Google over privacy - <AUTHOR> http://www.bbc.co.uk/news/technology-32083188

<comment><USER2> This seems to be from the mobile iframe workaround that Google implemented. Apple decided that Safari should not allow an iframe with different source urls to drop cookies unless the user interacts with the iframe (clicks something in it). Google's iframed ads automatically clicked something in order to drop a Google cookie.

I feel that Google didn't get enough shit for this. They kinda get a pass for their shitty behavior.

<comment><USER3> Thanks for the explanation, I was genuinely struggling to understand what it is they actually _did_ based on the story... I know it's intended for a mainstream audience but at least some technical info would've been useful!

</comment></comment><comment><USER4> While this is obviously great for privacy proponents - I still can't understand how, legally, Google must acknowledge and adhere to browser settings.

Does this set precedent for that?

<comment><USER5> To not adhere to the user's wishes (in this case, through browser settings) is malicious behavior.

<comment><USER4> So then if I write code that works around an ad-blocker, am I being malicious?

I'm not sure those two are actually equivalent, but it feels like it in this case - in which case this would be pretty bad precedent.

</comment></comment></comment><comment><USER6> evil is as evil does.</comment>


Not sharing your Facebook password could lead to prison - <AUTHOR> https://www.independent.co.uk/life-style/gadgets-and-tech/news/facebook-password-ripa-law-prison-lucy-mchugh-a8517176.html <comment><USER2> There is a murder-investigation going on and people are trying to be protective about their Facebook password. What kind of world am i living in?</comment>


Looking Back at Antitrust, the Movie Where Bill Gates Murders Coders - <AUTHOR> https://www.theverge.com/2018/9/7/17827992/antitrust-tim-robbins-bill-gates-microsoft-retrospective <comment><USER2> If you haven't seen this movie, it's a fun movie. Of course there are going to be some stretches here and there, but it's a tech thriller, not a documentary on open source software. At the very least, it stayed far far away from immersive GUIs and implausible computer behaviors.</comment>


'Trojan horse' anticancer drug disguises itself as fat - <AUTHOR> https://news.northwestern.edu/stories/2019/07/trojan-horse-anticancer-drug-delivery-disguises-itself-as-fat/ <comment><USER2> Can someone please eli5 how the regular human cells won't let the new delivery system in while the tumor cells will? Isn't the recognition of fatty acids the same?

</comment><comment><USER3> The paper:

[https://pubs.acs.org/doi/10.1021/jacs.9b04272](https://pubs.acs.org/doi/10.1021/jacs.9b04272)

They really get dramatic with these press release titles huh?</comment>


This is what Flash can do in 2008 - <AUTHOR> http://blog.alternativaplatform.com/ru/files/2008/01/characterparallax.swf

<comment><USER2> Here is a very similar effect in canvas:

[http://29a.ch/2010/3/24/normal-mapping-with-javascript- and-c...](http://29a.ch/2010/3/24/normal-mapping-with-javascript-and-canvas- tag)

<comment><USER3> It's so slow.. According to hackermom the 14Mhz Amiga could do this at 25 fps, any idea why this is so slow on modern computers?

<comment><USER4> Because it's running in canvas? In other words, it's running within abstraction layer upon abstraction layer, with various other abstraction layers involved to help make sense of the fact that there are too many abstraction layers.

The amiga code was probably pretty close to talking to the graphics driver directly. Canvas is cool, but in terms of performance it's never really going to compete with native code, or even with flash for that matter since flash can remove some complexity by only building for a single, predictable, optimized environment.

<comment><USER5> "Graphics driver" still sounds too complex. The code was probably poking bytes to the memory segment mapped directly to the display - just like in DOS days, where each byte of the 0xA000 segment represented a pixel when using a VGA 320x200 resolution, 256 colors palette.

</comment></comment></comment></comment><comment><USER6> A bit of context: this is a demo showing parallax mapping, which was a soon- to-be-released feature of the Flash-based Alternativia engine at the time. It's was never supposed to be a state-of-the-art demonstration of Flash.

[http://blog.alternativaplatform.com/en/2008/01/04/character-...](http://blog.alternativaplatform.com/en/2008/01/04/character- parallax/)

</comment><comment><USER7> Not respecting dvorak keyboard layout, even in 2008?

<comment><USER8> Lack of universal acceptance was one of the cons you either accepted, or naively overlooked, back when you decided dvorak was the way to go. It'd be nice to see it work in more places, sure, but it just ain't... you're conflating 'should' and 'could'.

<comment><USER9> A snarky Apple fan could respond in the same way with regard to the absence of Flash on the iPhone products.

<comment><USER10> And additional mouse buttons.

</comment></comment></comment></comment><comment><USER11> And how would this improve the web experience? (considering you can do similar stuff with canvas as well...)

</comment><comment><USER12> One word: Indeed.. <http://twitpic.com/1l9b7k>

</comment><comment><USER13> I remember something exactly like this except it was an Asian lady and it looked like a real photo. Also instead of looking away from the cursor her eyes were following the cursor.

</comment><comment><USER14> This sure is impressing, but nobody said Flash doesn't have some good features. The question is about whether anybody who wants to can implement a player for this page.

<comment><AUTHOR> [http://blog.alternativaplatform.com/ru/files/2008/04/bunker....](http://blog.alternativaplatform.com/ru/files/2008/04/bunker.swf)

and

[http://blog.alternativaplatform.com/ru/files/2009/02/hero.sw...](http://blog.alternativaplatform.com/ru/files/2009/02/hero.swf) (press space to rotate)

<comment><USER15> With HTML5

<http://www.benjoffe.com/code/demos/canvascape/textures>

<comment><USER16> Neat. This example is nowhere near as pretty as the Flash examples, but it's interesting that my CPU is barely doing anything even when walking around. In the Flash version my CPU is pegged just sitting there doing nothing.

<comment><AUTHOR> I am pretty sure if HTML5 implement the same scene as bunker.swf it would hog much much more CPU.

<http://www.ponticstar.com/projects/burning-words/>

Try set the font to 100, and see if it's still as smooth as you thought.

<comment><USER17> Canvas is by all means a CPU hog and much slower than software-mode Flash.

<http://vimeo.com/10553088>

But hey, Flash is dying, etc

<comment><USER18> Flash Games, demos, and webcomics are nice.

However:

No matter the codec or operating system, we should not NEED Flash to view video on the Web.

<comment><AUTHOR> i completely agree

however, suppose you are about to design a video site for the common public back in 2005, what technology would you choose? quicktime? realplayer? windows media player?

i dont think flash video is unneeded any soon, even if html5 has a 70% adoption rate, people would still need flash for h.264 fallback

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> I am not an atomic playboy!

<comment><USER20> And that was 1993. <http://www.youtube.com/watch?v=XtCW-axRJV8#t=4m40s>

</comment></comment><comment><USER21> It's just plain displacement mapping. It's a very simple (and old), but versatile technique allowing a large amount of effects to be done. The first time I saw this was in 93 or 94, rendered in real time in 256*256 in 25 fps, on an Amiga running a 14mhz 68020 processor. THAT was impressive to me, but seeing this 15 years later in 15-20 fps in Flash on a 2ghz machine just isn't.

<comment><USER22> Exactly. And flash was introduced 14 years ago. It really has no excuse for not having better performance at this point. I'm glad its dying.</comment></comment>