Rust 1.45 - <AUTHOR> https://blog.rust-lang.org/2020/07/16/Rust-1.45.0.html <comment><USER2> > Rust 1.45.0 adds the ability to invoke procedural macros in three new > places!

Rust 1.45 will be the Rocket Release. It unblocks Rocket running on stable as tracked here [https://github.com/SergioBenitez/Rocket/issues/19](https://github.com/SergioBenitez/Rocket/issues/19)

This is so excellent, and I love seeing long term, multiyear goals get completed. It isn't just this release, but all the releases in between. The Rust team and community is amazing.

<comment><USER3> For those out of the loop like me, Rocket is a web framework for Rust that apparently was using a lot of experimental features. [https://rocket.rs/](https://rocket.rs/)

Or maybe it's an explosive weapon crafted with metal pipe and gunpowder. [https://rust.fandom.com/wiki/Rocket](https://rust.fandom.com/wiki/Rocket)

<comment><USER4> Hadn't heard of it, but it looks a lot like flask. Good stuff, maybe I should consider looking into Rust after all.

</comment></comment></comment><comment><USER5> This rather niche fixing of unsafe behaviour is excellent: [https://blog.rust- lang.org/2020/07/16/Rust-1.45.0.html#fixin...](https://blog.rust- lang.org/2020/07/16/Rust-1.45.0.html#fixing-unsoundness-in-casts)

I spent a few years as a scientific programmer and this is exactly the sort of thing that just bites you on the behind in C/C++/Fortran: the undefined behaviour can actually manifest as noise in your output, or just really hard to track down, intermittent problems. A big win to get rid of it.

<comment><USER6> I'm not sure I understand this. Does it not produce a run time error? Why not?

This looks very dangerous, because it essentially does the "nearest to right" thing. Say, you cast 256 to a u8, it's then saturated to 255. That's almost right, and a result might be wrong only by 0.5%. Much harder to detect than if it is set to 0.

<comment><USER7> > I'm not sure I understand this. Does it not produce a run time error? Why > not?

It's not supposed to. Type casting with 'as' is supposed to be lightweight and always succeed; there is no room in the type system to return an error. In case lossless casting is not possible, some value still has to be returned. Until now, this was outright UB — meaning the compiler is not even obligated to keep it consistent from one build to another. Saturating, while still not optimal, is at least deterministic.

> This looks very dangerous, because it essentially does the "nearest to > right" thing.

That's why the intention is to introduce more robust approximate conversion functions and eventually probably deprecate 'as' casts altogether. There has been a number of discussions about this; current disagreements seem to be about how to handle the various possible rounding modes.

<comment><USER8> > meaning the compiler is not even obligated to keep it consistent from one > build to another.

Way worse than that. The compiler wasn't obligated to act like anything at all. It would be totally legal to compile it so that the first time the value was accessed you got 0, the next time you got 1 - within the same program execution, with no mutation of the value. _That_ is the sort of thing that is observed behavior of UB in the worst cases, and why it's so terrible to just pretend that UB is innocuous.

<comment><USER9> _Way_ worse than that, even. UB poisons every state of the program that _eventually_ results in UB. For example, the optimizer is well within its rights to remove as dead code any branch that, if taken, would provably lead to UB at some arbitrary future point of execution.

<comment><USER10> That could literally produce no output program?

<comment><USER11> Yep! Dumb example.

        main()
          x = get_from_some_external_data_source()
          if x:
            print("Hello World")
            trigger_ub()

You might expect this code to always print if x is true but the optimizer can look at this and say "welp, if x is true then it would trigger ub, therefore it must be false, and since x must always be false we can just remove that entire branch."

<comment><USER12> My favorite example along these lines (in C) is "Cap'n'Proto remote vuln: pointer overflow check optimized away by compiler"[1] which was covered here a few years back and shows all of these "theoretical" compiler behaviors coming to a head in a real bug which is thoroughly explained.

1: [https://news.ycombinator.com/item?id=14163111](https://news.ycombinator.com/item?id=14163111)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> I keep seeing more and more news about Rust, and figure that perhaps it is time that I learn something new.

99% of my development work these days is C with the target being Linux/ARM with a small-ish memory model. Think 64 or 128MB of DDR. Does this fit within Rust's world?

I've noticed that stripped binary sizes for a simple "Hello, World!" example are significantly larger with Rust. Is this just the way things are and the "cost of protection"? For reference, using rustc version 1.41.0, the stripped binary was 199KiB and the same thing in C (gcc 9.3) was 15KiB.

<comment><USER14> The smallest Rust binary ever produced was 145 bytes. [https://github.com/tormol/tiny-rust- executable](https://github.com/tormol/tiny-rust-executable)

That is a bit extreme but it demonstrates the lower bound.

There's a lot of things you can do to drop sizes, depending on the specifics of what you're doing and the tradeoffs you want to make.

Architecture support is where stuff gets tougher than size, to be honest. ARM stuff is well supported though, and is only going to get better in the future. The sort of default "get started" board is the STM32F4 discovery, which has 1 meg of flash and 192k of RAM. Seems like you're well above that.

<comment><USER15> > ARM stuff is well supported though

FYI Rust (and Go) currently don't work on the new Apple ARM macs.

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

<comment><USER14> That is not _entirely_ correct for Rust. I know because I helped a friend of mine debug the porting process. (Apple did not see fit to give me access to the hardware, alas.)

[https://github.com/rust-lang/rust/issues/73908](https://github.com/rust- lang/rust/issues/73908) has the full details.

(Also, not to be super pedantic, but this (among other things) is partially why I said "and is only going to get better in the future," that is, the support is generally good (I know, I am literally doing some of that in another tab right now) but not flawless.)

<comment><USER15> Very interesting, thanks for the link!

<comment><USER14> You're welcome! And I'm sorry you're downvoted, I think that's a little overly harsh. Had I not known, that would have been helpful.

</comment></comment></comment></comment></comment></comment><comment><USER16> > array[i] will check to make sure that array has at least i elements.

At least i+1 elements, right? Or am I getting caught up by one of the three hardest problems again?

<comment><USER17> Edit: brain not woken up yet. It's because of zero indexing.

———-

Original question: Out of curiosity, why the +1?

<comment><USER18> Arrays start at 0. example_array[5] is actually the 6th number in the array.

<comment><USER17> Ah yeah that makes sense. I was thinking the `i` check already accounted for the zero indexing.

</comment></comment></comment></comment><comment><USER19> [https://github.com/SergioBenitez/Rocket](https://github.com/SergioBenitez/Rocket) on stable rust finally!

<comment><USER20> IMHO, it's a shame So Much time has been spent (~3 years ?) on async at the cost of basic features like multipart and CORS.

But I understand it could be more fun for the devs :-)

<comment><USER21> I think it makes sense to get your foundation and ergonomics correct before piling on features. Otherwise you end up building features that may need to be completely restructured/redone later.

<comment><USER22> I recently switched from old sync versions of hyper and postgres to the new async versions. [1]

It wasn't hard, but yeah it was not fun either.

I can only imagine it's worse if you're actually writing the libraries and not just a CRUD app like I am

[1] Apparently the postgres crate was a wrapper around tokio_postgres all along and I didn't notice. So to remove a dependency I switched to using tokio_postgres directly

</comment></comment></comment></comment><comment><USER23> By any chance if anyone is in the Paris area and is interested to teach Rust at university next year during the first semester. Please get in touch :).

<comment><USER24> Is this undergrad? Genuinely curious, how will you get someone to understand what ownership helps avoid without them having experienced the pain on the other side?

I guess with younger and younger kids learning programming these, may be there can handle more? I am not sure if my son would understand all of the intricacies in his first semester.

<comment><USER23> Yes it is a course aimed at undergrad students, in their second year at university.

Of course they won't be able to grasp everything that Rust has to offer, but that is true of any language. I think Rust will expose them to many theoretical and practical CS concepts that they will be glad to have at least heard of during their studies.

In our degree, the first year students learn to program with Python, Racket (or OCaml depending on which teacher they get), C, Prolog, Bash, … Each of these language have way more to offer than what they can grasp. But each of them offers a different approach to programming and help the students to actually learn to _program_ (rather than learning to _write Java code_ , for example).

The course in question is actually called "Advanced programming". I want to experiment with a Rust course in second year as a kind of followup to both the functional programming course (the Racket/OCaml one) and the imperative programming course (the C one) that they have during the first year. If it really doesn't work, we'll change for something else or simply swap back to it being "Advanced C programming" for instance. But first, let's try to make the Rust experiment work. I really think it can benefits our students!

<comment><USER24> sorry, when you said first semester, I assumed you meant first semester of the 4 yr course, as in intro classes. But you probably meant first semester of this year. Either way, it is good to experiment. Thank you for doing that.

</comment></comment></comment></comment><comment><USER25> I'm building an embedded project that currently runs a python script for automatic brightness. It takes a brightness value from a sensor over I2C, applies a function to get an appropriate LCD brightness value and then sends that to the display driver over a serial port. Would this be an appropriate project to write in Rust to learn the basics of this language?

<comment><USER26> Yes. We used Rust to drive a few things via GPIO and USB-RS232 a few years ago on a Raspberry Pi, it was a pretty pleasant experience.

Maybe take a look at this I2C lib: [https://github.com/rust- embedded/rust-i2cdev](https://github.com/rust-embedded/rust-i2cdev)

</comment></comment><comment><USER27> As someone who hasn't used Rust, I am curious about why Rust has macros.

I use C++ at work, which admittedly isn't the language I use most, and macros are used quite a bit in the code base. I find they just make the code harder to read, reason about, debug, and sometimes even write. I don't see them really living up to their claimed value.

Is there something different about Rust's macros that make them better?

<comment><USER28> There is almost no intersection between the kind of things that can be done with the C++ macro system and the kind of things that can be done with the Rust macro system. They are not related. You can see them as another feature that is not available from C++.

<comment><USER29> You can get quite close to the use case for Rust macros by considering C++ template-based metaprogramming. Of course the biggest difference is that Rust macros have been designed from first principles, not as a clunky afterthought.

</comment></comment></comment><comment><USER30> If you have been on the fence about learning Rust, I encourage you to dive in. It is very productive.

<comment><USER31> How is the build system? Is it stable and easy?

<comment><USER32> In my experience, Cargo is much easier and more reliable than the systems I've used across Java/C++/Scala/Python/Go/JavaScript. It is such a pleasure to use.

</comment></comment></comment><comment><USER33> The post says

      The new API to cast in an unsafe manner is:

      let x: f32 = 1.0;
      let y: u8 = unsafe { x.to_int_unchecked() };

      But as always, you should only use this method as a last resort. Just like with array access, the compiler can often optimize the checks away, making the safe and unsafe versions equivalent when the compiler can prove it.

I believe for array access you can elide the bounds checking with an assert like

      assert!(len(arr) <= 255)
      let mut sum = 0;
      for i in 0..255 {
        sum += arr[i];//this access doesn't emit bounds checks in the compiled code
      }

I'm guessing it would work like this with casts?

      assert!(x <= 255. && x >= 0);
      let y: u8 = x as u8; // no check

<comment><USER34> It should be `assert!(len(arr) >= 255)` (greater instead of less than), right?

<comment><USER21> If you want to omit a bounds check, the compiler needs to know that the length of the array covers the upper bound of the loop, right?

<comment><USER35> If the array length is known to be _strictly_ less than 255 then there is definitely an out-of-bounds access inside the loop, but since this is a panic rather than undefined behavior it could matter how many loop iterations are executed before the out of bounds access occurs, so the check can't be omitted.

If the array size is definitely greater than _or equal to_ 255 then all the array accesses in the loop will be in bounds and no further bounds check is required.

<comment><USER21> Oh, right.

</comment></comment></comment></comment></comment><comment><USER36> Rust has come a LOOOOOONG way. I'm really impressed with what they've accomplished in just a short time.

</comment><comment><USER37> Can we please deprecate the "as" operator?

Something so lossy and ill-conceived should not be a two-letter operator.

<comment><USER38> Then what do you propose for replacement? C++ style casts `(int) x` ?

<comment><USER37> into()/try_into() and methods designed for each of the other cases (e.g. truncate(), saturating_to_int(), approx_to_float(), etc.)

</comment></comment></comment><comment><USER39> Any algo-trading backtest frameworks in Rust?

<comment><USER40> All you need for algotrading is to query an api. Rust would be a poor choice for that anyways, like using a semi truck to carry your bike around.

<comment><USER41> Performance is super critical in high frequency trading, so Rust sounds like reasonable choice. Having your code run a millisecond faster means beating out a competitor with the same algorithm as you, getting you a better price.

<comment><USER42> Be aware that Rust gives you the tools to be fast, it is not necessarily fast by default, although a lot of constructs it guides you towards usually help with that. You still need to profile your code to see what you need to optimize, whereas other languages with fewer knobs _will_ perform optimizations that you otherwise need to manually annotate in your code in Rust. I prefer this approach, but it _can_ be surprising to people used to the alternative.

<comment><USER43> Do you have examples of this? I'd be curious to know if so. (I've played w/ Rust a little bit -- I implemented a Boggle board scorer + high-scoring board generator; Rust outperformed my C++ code! I was impressed.)

<comment><USER42> One example of the _choice_ you have is how you can deal with generic data types:

      fn foo<T: Trait>(_: T){}
      fn foo(_: impl Trait) {}
      fn foo(_: &Trait) {}

These three different fn definitions have two different behaviors and affect both the speed of the code and the speed of compilation and it depends entirely on how they are called.

The first one is what the language calls generics: they are always monomorphized, which means that if you have three calls to `foo` with different types (that implement Trait) the compiler will expand three different functions with different types (code expansion).

The second one is a separate syntax level feature (impl Trait) which was mainly added to introduce a _new_ feature which is static opaque types, where the _function_ determines what the underlying the return type will be, but the caller can only interact with it using the trait's API.

[Aside] This is useful for cases like the following:

      fn it() -> impl Iterator<Item = i32> {
          vec![1, 2, 3].into_iter()
      }

where you would otherwise have to specify the specific type:

      fn it() -> std::vec::IntoIter<i32> {
          vec![1, 2, 3].into_iter()
      }

This example doesn't seem like much, but if you want to add a `map()` call to this you start to see the benefit:

      fn it() -> impl Iterator<Item = i32> {
          vec![1, 2, 3].into_iter().map(|x| x * x)
      }

      fn it() -> std::iter::Map<std::vec::IntoIter<i32>, fn(i32) -> i32> {
          vec![1, 2, 3].into_iter().map(|x| x * x)
      }

The more types you nest the more the benefits come into play. [end of aside]

Now, with that out of the way, the type of an impl Trait in argument is decided by the caller (not the function), so they are implemented internally exactly the same as type generics. The only difference is arguable nicer syntax in the definition and not being able to specify a type using the turbofish. For all intents and purposes, those two are the same feature.

The third function is different, it uses a virtual table, with everything that implies: there's type erasure, there's only a single function in the expanded code (which makes compilation faster because the compiler doesn't need to do work), calling this function _can_ be slower because the final executable has to perform some pointer chasing to call methods, instead of directly knowing where to call them.

All of this to say: if you use `fn foo<T: Trait>(_: T)` or `fn foo(_: &Trait)` affects compilation and execute time, so you have to be aware of their distinction. This means that if you're _not_ aware you might have slower code than you would with a compiler (like Swift, for example) which relies on heuristics to decide to do static or dynamic dispatch, but it also means that your code's performance characteristics won't change all of a sudden because you modified a tangentially related part of the code and suddenly crossed some threshold.

Another example can be `.clone()`: is it slow? The answer is always "it depends". You might be cloning an `Arc`, which is cheap, you could be cloning a 10MB string, which is slow. But because we train ourselves to see clone as slow we might be worried or annoyed by `Arc`. We could make it `Copy`, but if we did _that_ then you have _less_ control over where the `Arc` gets copied which would make it harder to keep track of where the RC gets incremented. The language also doesn't automatically implement `Copy` for small structs, even though it could, which would make it easier to learn that part of the language (you don't learn to add derives early on), at the cost of baffling behavior (you might add a field and suddenly your struct isn't considered "small" anymore).

Yet another example, you also have access to `Cow<'_, str>`, which lets you deal with both static and heap allocated strings in the same way in your code, but it pollutes your code, where the naïve thing to do would be to use `String` everywhere.

My personal wish is for Rust to remain explicit as much as possible, but use lints to emit suggestions for the cases where a more "magic" language would change the emitted code. That way the code documents its behavior with fewer surprises.

<comment><USER43> Thanks!

The monomorphization-vs-dynamic dispatch thing feels natural from a C++ perspective, as it completely mirrors the choice of achieving 'polymorphism' via templates or virtual methods (though of course the Rust syntax is way nicer!, using traits for both, whereas in C++ you have either a class definition or...nothing, just ungodly compile errors ("compile-time dynamic typing")).

That's interesting re Swift. It seems similar in a way to using heuristics to decide whether to inline a function or not.

I _think_ C# does monomorphization for value types ("struct") and vtables for reference types ("class"), though I wouldn't bet on it...

> fn it() -> impl Iterator<Item = i32> {

One of the things that impressed me w/ rust was being able to write really concise code using ".map()" and friends and finding that it all ended up running just as fast as raw loops.

(The thing that has _most_ impressed me about rust was the crossbeam crate + type system + derive stuff, which let me parallelize board search in an incredibly easy fashion. I found it much nicer to work w/ than Go channels, which is supposedly one of Go's big tricks!)

</comment></comment></comment></comment></comment></comment></comment><comment><USER44> Doesn't this mean that a conditional branch is added to all existing code which performs casting?

<comment><USER45> I think in the specific case of casting a float to an int, more instructions will be added, but it doesn't have to be a branch. Here it looks like rustc emits a conditional move: [https://godbolt.org/z/1cfqof](https://godbolt.org/z/1cfqof)

</comment></comment><comment><USER46> this is extremely exciting, a truly wonderful release.

well done rust team

</comment><comment><USER47> > Just like with array access, the compiler can often optimize the checks > away, making the safe and unsafe versions equivalent when the compiler can > prove it.

Can it "often" solve the halting problem as well?

The hope that this kind of optimization will happen sounds a bit fanciful for any non-trivial part of a program.

<comment><USER14> You would be surprised, at least with array access stuff. And, if it doesn't, you can often help it understand with a bit of work. Sometimes an assert before a loop or re-slicing something can take a check in the body of a loop and move it out to a single one.

I ported a small C function to Rust recently that involved some looping, and all of the bounds checking was completely eliminated, even once I took the line-by-line port and turned it into a slightly higher level one with slices and iterators instead of pointer + length.</comment></comment>


MediaTemple DOS Attack - <AUTHOR>

I was up coding last night, and SSH latency skyrocketed around 2AM. Sent a support request to mt and got this response:<p>"There was a brief episode of latency due to a DOS attack, as a result our system engineers did a firmware update to the firewall. Our System Engineers have completed the emergency maintanence and all services are now running normally again. We will update all of our affected customers with details of this outage as soon as we have made a complete investigation."<p>Still nothing posted on their System Status page. We're using a Grid-Service account for dev. This plus the recent "storage performance" issues means we're definitely switching to another host. <comment><USER2> Yeah, I got hit by the same issue around that time last night. I've been using gridserver for dev purposes, but wouldn't dream of hosting a production app on there.

They're good for something like a blog, though - I believe that was the main idea behind the grid, to survive the Digg effect or something.

</comment><comment><USER3> I'm using the Dedicated Virtual service, which I presume isn't as bad as some people describe Grid. My site doesn't have the traffic to test it out. Also, Nitro is another service I know little about. Has anyone had good experience?</comment>


Ask HN: Is it just me or is the AMP project making everything slower? - <AUTHOR> I have µMatrix in my browser, and by default it blocks the AMP CDN. The result of this seems to be horrendous white-screen times for web-pages, beyond what I would expect it to take for a web-server to load these pages, and the delay in loading is very noticeable across all of them.
I have a vague idea of the point of AMP, which is to speed up the delivery of web pages. However:
1) I'm not convinced the web pages were really _that_ slow to start with, so it feels like an unnecessary project (well, excepting the fact that web-page bloat has massively increased as people use more and more javascript libraries &c.).
2) Perhaps I'm being a bit old fashioned, but I don't really understand what was wrong with a browser serving a web page made out of some HTML, CSS, and Javascript. It feels like we're replacing one technology with another (and that latter one comes from Google, which makes me nervous). Do we really want AMP to be the way we serve the web?
3) I haven't properly investigated, bt I'm assuming that this delay is some script which is waiting for the data to load from the AMP CDN, and once that times out it displays the underlying content (I did check and loading this page [1]  is almost instantaneous yet the content only displays after three seconds). Any insight into why it's seen as acceptable for this to be so slow when it is unnecessary for displaying the page?
[1]: https://www.ehow.co.uk/how_5840711_test-electrical-outlet-digital-multimeter.html <comment><USER2> I sadly have to code AMP for work. The reason you see a white page is that the boilerplate code required for any AMP page to be valid includes :

      webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;

With visibility set to hidden for every element on the page. This is used to minimize page rendering artifacts for the end user, which is one of AMP's main goals, content should be fixed.

The problem however here is that this animation is usually triggered before the 8s, as soon as the AMP javascript has been served from the CDN. Your adblocker of something of the sort is blocking it which results in you having to wait for the hard coded 8s fallback to see the page no matter if the content is already loaded.

AMP is beautiful.

<comment> black-tea 8 seconds! I remember browsing the Web in the early 2000s on a good connection and pages loaded fully in a matter of milliseconds. It was often imperceptible. Oh how we've regressed.

<comment><USER3> >I remember browsing the Web in the early 2000s on a good connection and pages loaded fully in a matter of milliseconds.

That has to be rose-tinted glasses. Networks used to be excruciatingly slow. I would walk away waiting for page loads during the dial-up era. Our expectations have simply been adjusted over time.

<comment><USER4> If black-tea had a good connection at a time when the rest of us were on dial- up, and all the sites were coded expecting dial-up, they may well have seen excellent load times!

(But yeah, I remember the internet being super slow. JPEGs coming down scanline-by-scanline.)

</comment></comment></comment></comment><comment><USER5> >I'm not convinced the web pages were really _that_ slow to start with, so it feels like an unnecessary project (well, excepting the fact that web-page bloat has massively increased as people use more and more javascript libraries &c.).

Right. It's super easy to make lightning fast web pages. In fact, that's the default state of a static HTML page. It actually takes a lot _more_ work to make pages slow by adding tons of javascript, dependencies, server-side applications, etc.

From the article linked elsewhere in this thread: >The 90th percentile weight for the canonical version is 5,229kb. [...] The 90th percentile request count for the canonical version is 647

There's the problem. Over 5 megabytes and 647 requests for one article? 5MB is equivalent to about 20 full-length novels or 1,000 pages of text. And 647 requests?! That must be one extremely comprehensive article, right? No, it's 1 request for a brief article and 646 unnecessary requests wasting bandwidth to load unnecessary stuff. Then people wonder why it's slow. But someone put in a lot of work to fluff that page up to be that huge and slow and use that many requests.

<comment><USER6> > The 90th percentile weight for the canonical version is 5,229kb.

I get antsy when I made a page over 100KB (excluding images, and even then anything over 1MB starts to feel excessive unless it's something particularly reliant on images). 5MB feels very high.

<comment><USER7> I'm with you, but it's the reality. I just searched for "NASA" on google news, clicked the first thing not from JPL ([https://www.fool.com/investing/2019/01/12/whos-who-in- nasas-...](https://www.fool.com/investing/2019/01/12/whos-who-in-nasas-next- space-race.aspx)) and it loaded _2.6MB_ cold cache.

Fetched the same on the AMP Cache: [https://www-fool- com.cdn.ampproject.org/c/s/www.fool.com/amp...](https://www-fool- com.cdn.ampproject.org/c/s/www.fool.com/amp/investing/2019/01/12/whos-who-in- nasas-next-space-race.aspx) _200KB_ cold cache. Removing the likely cached resources (amp javascript, fontawesome cdn font) and the payload is _~35KB_.

It's certainly possible to make a lightweight page, as hacker news is a great example, but people aren't doing it. For whatever reason, AMP seems to be effective at making the web actually follow best practices.

<comment><USER8> No it's not. All the AMP websites I've seen were just as bad as their non-AMP counterparts. Reddit's AMP pages in particular, are slow and immensely frustrating to use.

</comment></comment></comment></comment><comment><USER9> Yes, AMP is rather slow: [https://timkadlec.com/remembers/2018-03-19-how-fast- is-amp-r...](https://timkadlec.com/remembers/2018-03-19-how-fast-is-amp- really/)

and looks fast mainly because Google preloads it: [https://ferdychristant.com/amp-the-missing- controversy-3b424...](https://ferdychristant.com/amp-the-missing- controversy-3b424031047)

<comment><USER10> Sure, but from an end-user perspective, preloading is a perfectly valid way to achieve good performance, so it shouldn't be left out of the conversation. The fact that AMP can be preloaded without leaking your sensitive information to the owners of domains that you have not yet navigated to is a primary component of the design, and often gets ignored by armchair analysts.

<comment><USER11> The problem is that preloading is brittle. I see AMP pages lagging only a daily basis which is much rarer for sites which follow best practices — that 100KB of render-blocking JavaScript makes AMP incredibly brittle.

<comment><USER12> The web isn't what it was back in the 90s and early 2000s though. Back then, you wanted a website to last because there wasn't much on the web to begin with. Those of us who were online owned a reasonable amount of web bookmarks that led us to nice solid pages that were designed to load nice and fast over slower connections.

Nowadays, the landscape is way different. There are just so many "normal folk" on the internet now that content is being consumed at an alarming rate. There is so much stuff on the internet now, that even Youtube videos have become disposable. Most of the stuff that people read and watch now is consumed once and then never visited again because there's just not enough time to revisit the insane amount of content we're exposed to.

Nowadays, why does it matter if a website is made "brittle" if the content isn't going to matter in a few months anyways? And if you do want to archive something for later, shouldn't the words on the page matter more than the code behind it? After all, if a user 12 years from now wants to read your article, all they're going to want is your words and pictures. Code is always brittle because new technology makes everything obsolete.

<comment><USER11> Having been a web developer in that era, performance was definitely a big concern. People were more willing to wait but there were still limits and you had the same tendencies for developers to work on fast systems and forget the experience on slow ones.

AMP is also a worse experience than that was because in the 90s you were usually waiting on images to render and progressive display was usually possible so you could start seeing that fuzzy JPEG fairly quickly and read the rest of an article, whereas AMP by design prevents anything from displaying until it's loaded and executed correctly so you often have to reload the page to see anything at all when it fails.

This matters because most of where AMP was marketed to are competitive fields and that means it's training users that they'll get what they want faster and more reliably somewhere else.

<comment><USER12> I remember browsing the web on my old Nokia N900 phone and watching everything get progressively slower as javascript started getting more and more memory intensive. Eventually I stopped receiving updates, and the entire web became unusable because lots and lots of websites break without javascript now.

</comment></comment></comment></comment></comment></comment><comment><USER13> The most frustrating is that AMP version of app/pages/websites are very incomplete, e.g. the AMP version of a reddit post has only 3 comments (and the "load more comments" button is buggy).

Would have been much better to use Lighthouse / PageSpeed as a basis for showing optimized pages.

<comment><USER14> Ugh, Reddit. Their amp version is terrible for the exact reason you mention. I know every time I see a Reddit page on Google results that I'll make two page loads instead of one (this does make a difference on my country, where everything is slow). Then, when accessing their pages on mobile browser, there's a huge banner telling me to download their app. In this same banner there is a dark UX pattern, where the call to action, giant button is to download the app, and the tiny footer text is "continue to mobile site". And apparently it doesn't matter I clicked through the banner before, it always displays the same annoying banner.

Sorry for the rant. I'm just genuinely disappointed in what the web has become.

<comment><USER15> My favorite is that they've recently started animating their "Get the app" button in the header. That's both immediately on page load, _and_ on an interval as you're reading, meaning it's impossible to read for more than a minute or so without an animation distracting you.

Is it just me or has the mobile web taken a nosedive in recent years? Imgur won't even let you upload images from mobile anymore without their app, reddit is getting progressively more annoying, "Get the app" buttons and modals and banners are getting progressively more prominent and dark-pattern-y, and the default for all web pages now seems to be to include <meta name="viewport" conent="width=device-width, initial-scale=1"> regardless of whether the developers actually tested that their web page works on small screens, meaning web pages which would've just fallen back to desktop emulation mode in the past just simply don't work at all.

<comment><USER16> The mobile web has always been utter trash, it's just gotten worse in the last five years as more sites have rolled out mobile versions.

Disabling Javascript helps a lot, but the "request desktop site" toggle is still frequently necessary.

Imgur is, however, deserving of special mention for _actively degrading_ their mobile experience - direct image links redirect to the mobile site now, which loads low-resolution images.

<comment><USER17> Imgur gets another point for loading images with (third-party?) JavaScript, so that it sometimes hangs on the fancy animated loading screen and I never see the picture unless I reload.

It's unfortunate that so much work goes into UX design but at the same time the web has been going downhill for years.

</comment></comment></comment></comment></comment><comment><USER18> I think there are definite drawbacks to the AMP project. For starters, it seems like the main goal is for Google to own more of the time people are interacting with the web, rather than anything else.

A mark in its favor though is local news sites. They are desperate to be at the top of the search page so when they join AMP, and you look at their AMP pages all of a sudden the loads of dark patterns they usually employ are absent.

<comment><USER11> Google could get the same effect by more aggressively factoring page load time & size into page ranking. They don't because that doesn't give them control over the ad ecosystem.

<comment><USER19> They did that for years already, I believe. It didn't work.

<comment><USER20> I'm not sure if that's true. Even now they claim that page speed is only a small factor in overall page rank, and even _that_ applies to "only the slowest sites." [https://webmasters.googleblog.com/2018/01/using-page- speed-i...](https://webmasters.googleblog.com/2018/01/using-page-speed-in- mobile-search.html)

</comment></comment></comment></comment><comment><USER21> I finally deployed code a few days ago to rewrite AMP urls on HN. It's tricky to get right. Fortunately Brian Eno was not playing.

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

<comment><USER3> Shouldn't HN be grabbing the canonical URL from submissions anyway?

</comment></comment><comment><USER22> > I have µMatrix in my browser, and by default it blocks the AMP CDN.

Maybe an unpopular opinion, but if you're getting a slow load/blank page because you're blocking parts of the content, yeah, "it's just you". Without the fallback mechanism that gets triggered after a few second, you'd just be stuck at the white page.

A good site will load faster than AMP, on a decent connection it may even be comparable to preloaded AMP. However, news sites have been pretty universally horrible at making good web sites. If someone stood behind their web developers and management with a whip, forcing them to build decent web sites and disallowing them from adding bloat, AMP would likely be unnecessary.

Part of the benefits of AMP is the possibility to preload, which allows for near-instant page opening from the search result page (unless you're blocking content, of course), the other part of the benefits is being that whip.

My overall experience with AMP has been positive.

<comment><USER23> _> If someone stood behind their web developers and management with a whip, forcing them to build decent web sites and disallowing them from adding bloat, AMP would likely be unnecessary._

sadly it's the management, marketers, sales who are standing behind them and holding the whip. Most places measure engineering quality by how many features you can push through your CI/CD pipe (minus the fault-reports, breakage that the pipeline generates).

When everything works perfectly it isn't appreciated as it indicates that engineering isn't running at full capacity. The same problem we have with security and all resilience topics: how do you measure & budget (or in security monetize) something that is supposed to be invisible to the end-user?

As for AMP it's not just a tire-fire it's a clear attempt to break the open web and create lock-in for competitors.

<comment><USER24> What's weird to me though is because I browse the internet on my phone a lot, there are some sites that are terribly slow (and prone to those weird "you've won an iPad" hacks).

The Huffington post is one. On an older phone or tablet, the site is unusable on iOS. It will crash, and sometimes freeze. Long articles fill in excruciatingly slow.

I would think in a data driven business, that there has to be significant numbers of people who actively avoid the site, and that they would want to minimize this.

Yet there seems to be no improvement over time.

I've sometimes wondered if it's because literally every person in engineering and management at company like Huffington Post have fast devices, and they don't notice how bad it is.

I find it paradoxical.

</comment></comment></comment><comment><USER25> They're likely unrelated issues, but I am not surprised that those outside Google's happy path experience severe performance issues. Gmail has been horrendously slow ever since they launched their terrible redesign, with initial page load taking 10+ seconds and actions like opening up emails taking several seconds. I can't help but think this is because I don't use Chrome.

<comment><USER26> No, it's slow in chrome, too.

Multi user Hangouts is also horribly broken in chrome (first user can't see or hear anyone).

</comment></comment><comment><USER27> So... you're blocking the AMP javascript from loading and then complaining that AMP is slow for you.

Have you tried not blocking the script?

<comment><USER28> Downloading a website sans scripts takes strictly less time than downloading and executing scripts. A website that hides its content for 8 seconds because scripts are disabled is a defective website which deliberately stops users from looking static content (amp uses css animation).

<comment><USER3> Ha. That's like removing a bunch of methods from a program and claiming it's broken when it crashes. What did you expect to happen when blocking half of a site's libraries?

<comment><USER28> News sites are _hypertext_ , also known as formatted text, and _not_ web-apps or programs which download and render websites. I expect news sites to load properly in the absence of _the AMP CDN_ (not "half the methods"), not deliberately hide content from users. (I feel the same way about blocking page rendering when web-fonts don't download when their http connections hang instead.)

EDIT: I just moved to desktop. If I block all scripts in uMatrix, OP's URL loads immediately (albeit with a full page of garbage above page content). If I block _external_ scripts in uMatrix, I have to wait 8 seconds before anything appears.

<comment><USER3> >News sites are hypertext, also known as formatted text, and not web-apps or programs which download and render websites.

No, there are many thousands of websites that render their content dynamically on the client - news or otherwise. Facebook, Twitter, and Reddit all make use of client-side rendering (and all provide news services).

>not deliberately hide content from users

Your browser also "deliberately hides content". It waits a few hundred milliseconds before triggering a paint, just to avoid content from jumping around. AMP pages do the same -- unless you break the mechanism of course.

<comment><USER29> > Facebook, Twitter, and Reddit all make use of client-side rendering (and all > provide news services)

Oh, come on. You and I both know that those are social media apps which act as news aggregators, and are not themselves sources of textual news articles. jimbo1qaz was clearly talking about the latter.

<comment><USER3> What is the meaningful distinction between news websites and non-news websites? Client-side rendering is just a technique which isn't specific to any industry.

</comment></comment></comment></comment></comment></comment></comment><comment><USER3> Correct. You've broken the page by blocking only some of the assets. AMP loads fine if you allow all scripts or disable Javascript completely.

<comment><USER30> Disabling javascript doesn't disable css animations.

<comment><USER3> The CSS animation only comes into play as a fallback mechanism. The AMP script will force a draw sooner otherwise.

<comment><USER7> Precisely. The exact code is here:

[https://www.ampproject.org/docs/fundamentals/spec/amp- boiler...](https://www.ampproject.org/docs/fundamentals/spec/amp-boilerplate)

Here it is pretty-printed and simplified to not have the vendor-specific stuff:

The first bit is for browsers with javascript, but where the network is poor and can't load the minimal required highly cacheable javascript file within 8 seconds. It uses CSS just in case javascript really isn't working anyway such as being disabled per domain or something. The second bit is for browsers without javascript - the page is unblocked immediately.

</comment></comment></comment></comment><comment><USER31> I wish Google would just heavily weight fast-loading, responsively-designed pages in pagerank and call it a day. There's no need for a weird problematic proprietary format.. It just smacks of a power grab to keep visitors on google.com.

<comment><USER4> _> There's no need for a weird problematic proprietary format._

The reason we need AMP now is that you can't otherwise preload a page in a privacy-preserving way.

Webpackaging will allow doing this without AMP though: [https://github.com/WICG/webpackage/blob/master/explainer.md](https://github.com/WICG/webpackage/blob/master/explainer.md)

(Disclosure: I work at Google on making ads be AMP.)

<comment><USER32> Are you sure this is going to be allowed at Google? Policy and all that. They don't exactly look to be condoning open standards in this regard. Would be happy if I am wrong though.

<comment><USER4> Google is one of the main groups working on it. For example, the draft [https://tools.ietf.org/html/draft-yasskin-dispatch-web- packa...](https://tools.ietf.org/html/draft-yasskin-dispatch-web-packaging-00) is by a Google employee.

</comment></comment></comment></comment><comment><USER33> AMP pages take forever to load for me with Firefox and uBlock Origin. When I open a news story from Google's recommendations, which always open to AMP pages, it pretty much always takes about 15 to 30 to show anything on screen. I instinctively edit the link manually nowto try to go to the non-AMP version, which typically loads the content in under 5 seconds.

<comment><USER34> If you're using Firefox, you can just use the Redirect AMP to HTML extension.

<comment><USER35> Or, an alternative approach that also works in Chrome: use DuckDuckGo. Actually early AMP, that was extremely broken, pushed me out of Google completely.

<comment><USER34> Still have a problem with shared AMP links in that case. I like the Safari approach where AMP URLs get converted back to their canonical URLs when shared.

</comment></comment></comment></comment><comment><USER36> AMP has always and will always be a garbage idea. Stop implementing AMP.

<comment> super-serial Over the last couple years Google has acted like a dictator on the web. No more autoplay... except if you're Youtube, or these 100 approved sites. If you use Chrome... oh now you're auto signed in. You opt out of location tracking - we'll still track you, we don't care.

Don't give Google more power.

Implementing your website in AMP is basically handing the keys of the web over to Google. They're going to make it more and more ridiculous to stay AMP- compliant and you're going to be shut out if you don't play their game. Eventually they'll enable/disable features of AMP-based sites arbitrarily... similar to how they determine autoplay policy on their "approved sites list." Do you think Google should be the all-powerful being that determines what features you can have on your website? That's the future you're opting into if you implement AMP.

</comment></comment><comment><USER37> I don't know about slower, but it's certainly made the web more annoying to use with piecemeal javascript support - which obviously benefits advertisers like google, if it makes more of us cease interfering with tools like noscript and µMatrix.

</comment><comment><USER38> AMP is a project that benefits only a giant corporation. Please don't support it.

<comment><USER39> That giant corporation runs the biggest reason for SEO. AMP affects SEO.

</comment></comment><comment><USER40> The content of [1] displays immediately for me (and I do not have document scripts enabled). There are <amp-...> elements; I don't know what they are, and they do not do anything.

For webpages that do hide everything, I define my own CSS overrides which prevents the  and  element from ever being hidden, opacity less than 1, or similar. Further rules can be added to prevent  from being animated or having transitions.

What is wrong with just HTML, without CSS and JavaScript, or in some cases just plain text and not even HTML?

</comment><comment><USER41> AMP is about guarantees that you can't have with regular JS. You guarantee to not do any sync JS and document.write() stuff when you use AMP. Personally, I plan to use AMP to make a better indexation of my app which I do as a SPA, and which seems to be poorly indexed by Google. I'll make sitemap pointing to AMP pages with content, which has "see full view" link on it.

</comment><comment><USER42> Yeah, I actively avoid visiting AMP and sharing AMP sites for this reason whenever possible. They just take _so fucking long_ to load.

</comment><comment><USER43> In my experience AMP is considerably slower unless I happen to be browsing in Chrome. It's probably an accidental result of how they implemented AMP, that framework is tuned specifically for Chrome in the first place (odd CSS hacks to nudge Chrome's compositor into behaving a certain way, etc.)

<comment><USER44> "accidental"?

<comment><USER45> That's the joke.

<comment><USER46> Hey, where is my bitcoin!?

</comment></comment></comment></comment><comment><USER47> This is what's keeping the screen white before showing its content [https://news.ycombinator.com/item?id=17746886](https://news.ycombinator.com/item?id=17746886)

</comment><comment><USER48> Have I been under a rock?

I keep reading about AMP on HN, but I have yet (professionally or personally) actually come across AMP in the wild unless I intentionally went looking for it -- or am I consuming AMP and not even realizing it?

<comment><USER49> I don't believe that Google serves AMP links to Firefox, certainly not to the Mobile version and also not when you have JS disabled from google.com

Plus you might not be browsing the subset of AMPish websites. The only ALP links I see are when people share mainstream news links, and then it's straightforward enough to manually extract the URL.

</comment></comment><comment><USER50> It's outright blocking pages for me, until the pages retry without AMP

</comment><comment><USER51> It's junk and I hate it. Google isn't Yahoo but it's become replaceable in the same way that firm did. Google News has become a case study in what not to do.

</comment><comment><USER52> I wish I could opt-out of AMP, I dislike the reddit AMP experience as its poorly maintained compared the the web based mobile experience.

</comment><comment><USER53> AMP is IMHO the wrong solution for a stupid problem of bloating when simply making decent html pages would solve it very well.

</comment><comment><USER54> amp is slower than full pages for me. No custom configuration.

</comment><comment><USER55> > which is to speed up the delivery of web pages

...to make up for the slowness of all of the ads Google and others serve. It's amazing how fast pages load with no ad networks involved.

</comment><comment><USER56> Yes. I absolutely hate when I want to load an article on my iPhone and it loads AMP. I remove that part of the URL to read the original source most of the time.

</comment><comment><USER57> I refuse to work with AMP simply because it seems like the only reason for its existence is to retain more users permanently in the google "ecosphere". Making performant, fast loading websites has always been a priority for me and my employers, AMP isn't being integrated everywhere because companies want to make their pages load faster, they simply don't want to be penalized by google for not doing AMP.

So TL;DR AMP is rarely implemented for the right reasons, and the implementations reflect this.

</comment><comment><USER58> why not go all the way and just block websites that use amp? it's what i do. trend riding idiots are not worth it

</comment><comment><USER59> >I'm not convinced the web pages were really _that_ slow to start with, so it feels like an unnecessary project

That's because you use umatrix and possibly ublock.

AMP is about making the web faster for the common Joe.

<comment><USER10> It is also likely that you don't spend a significant amount of time browsing on a 2G cellular connection. When ping times are very long, the only way to get web performance anywhere close to native apps is pre-caching, which is what AMP is designed to enable (link-rel="prefetch" is a privacy nightmare). AMP is about the common Joe, but also about the 90th percentile slow performance (like in the developing world or on cellular networks).

<comment><USER60> Pre-caching in those cases will cause other things to slow down and needlessly consume bandwidth which the user is paying for.

The real reason for AMP is to allow Google to watch everything your visitors do so they can sell your visitors eyeballs to your competitors.

</comment></comment></comment><comment><USER61> AMP and PWA are pile of shits designed to lock users to Google.

</comment><comment><USER62> AMP is slow like s..t. Mess as a f..k.

</comment><comment><USER63> HTML seems like it has turned into cancer now...

I wonder what would be required for a format to not have this problem, and how it can be prevented.

</comment><comment><USER64> I have some 12 dev inspect tool for that style scripting this notebook was given to me by my gf and its a starter kit.

</comment><comment><USER65> It's not really AMP that delivers speed improvements that made everyone go WOW back when it started. It was the Google would prefetch AMP pages in search results.

In many cases AMP is neglibly faster than mobile web page and sometimes slower.</comment>


British Tourists' Tweets Get Them Denied Entry to the U.S - <AUTHOR> http://newsfeed.time.com/2012/01/31/british-tourists-tweets-get-them-denied-entry-to-the-u-s/ <comment><USER2> This is nearly three years old, and certainly has been mentioned before on HN, even if not actually submitted (although I was sure it had been submitted as an item in its own right.)

Is there any particular reason why you are submitting this now? Just wondering if you thought it was particularly relevant to something.</comment>


Shell Scripts vs. Ansible - <AUTHOR> http://devopsu.com/blog/ansible-vs-shell-scripts/ <comment><USER2> I still use shell scripts because I don't have the time or energy to invest becoming a domain expert in installing packages.

When my shell scripts become untenable I happily hire someone who is an expert at installing packages on a cluster of machines.

It's a complex problem and CMs so far are complex enough that I'm put off by how dense the CM language is. Every time I come across chef my ears start leaking precious brain fluid. Recipes, cookbooks, knives, bags, dependencies, acronyms I haven't bothered googling for... there's enough there that someone can dedicate their time to mastering it and be paid a decent salary.

No thanks, I'm already spending enough time as it is being an expert in something else. I'll just stick with shell scripts because at least I can understand those without much effort. If they become a problem I'll hire someone to fix it. :)

 _update_ : That was a little rant-y... after reading this article I might try Ansible if I get the chance. The problem I have with CMs is that they tend to be very complex because they solve a complex problem. Shell scripts tend to be simple (but crude by virtue). I am curious whether there is a middle-ground.

<comment><USER3> disclaimer: author of project here.

Achieving a middle ground was one of the points of creating the project -- making configuration tools more accessible to everybody, that you can forget and come back to in six months and still know how to work with.

I definitely would be interested in your feedback after your trying things, but I think that's exactly the point Matt was trying to make in the article.

<comment><USER2> Well the proof of the pudding is in the tasting... I will have to give it a whirl I suppose. Chef/puppet/etc seem easy on the surface when you're getting your feet wet. I find that the complexity monster rears its head when you have to start supporting multiple OSs and combinations of configuration options. Shell scripts fail in this area too but it's generally much easier to find the problem than a morass of metadata files, recipes, and specifications. I would be more than happy to provide feedback (being the curmudgeon that I tend to be).

I appreciate attempts at reducing complexity. I've been meaning to look into Marelle a bit ([http://larsyencken.github.io/marelle/](http://larsyencken.github.io/marelle/)) as I find logic programming and CBS to be where CMs should be heading. Is Ansible somewhere along that spectrum?

<comment><USER3> Ansible doesn't seek to be programming, so my guess is no. I generally am not a fan of that syntax and would disagree that that is the way most administrators and developers brains work -- but I guess I can see it for some who do think that way.

Multiple OSes are pretty straightforward though. Look at the 'group_by' module for dynamically carving up machines based on operating system, and things like the 'when' statement for introducing conditional behavior.

Variables can also be overriden based on groups, so you can define defaults in one group and then have different settings in other groups.

</comment></comment></comment></comment><comment><AUTHOR> This article will be preaching to the converted for many of you, but I still see so many folks still doing manual installs and shell scripts even for large companies that I felt I needed to try and convert a few more folks over to saner systems.

Fortunately Ansible has dramatically lowered the learning curve and now is a great time to make the switch. So, if you have friends that need an "intervention" from their manual installs, hopefully this will help you make your case to them :)

Of course there are many great config mgmt tools out there. I singled out Ansible because it's so simple to get started with and I've found that the learning curve is usually the biggest hurdle to adoption.

</comment><comment><USER4> I've used a lot of various configuration management systems over the years - CFengine, BCFG2, Puppet and now Ansible.

Two notes-

1) They all work well for the base cases, and make it much easier to handle hundreds of machines - Being able to say "Ensure libcurl is installed on appserver, and make sure that nagios has these plugins we wrote" is amazing.

But where every system starts to break down, is when we have setups that I have a good reason for, but don't fit into the preconceived notion of how to handle things.

For example, if I want to install a package from source, or if I want to manually wget a .deb from an internal server, then dpkg -i it.

What's nice is that most systems allow some flexibility - You can do 90% of things in the pre-written modules, and break out to do manual commands where necessary.

2) One thing I'd really like to see, though, is a system which operated with even LESS intelligence.

Rather than using YAML files, or any sort of "user-friendly" config, let me define variables and use pure Python to iterate and execute using them.

I'd love to have people give me pre-written modules as classes I can call, but having that exposed in a way I can get at it with native loops, if/then, etc, would make things a lot more straight forward.

        for server in webservers:

           server.ensure_perms('/var/lib/somefile',755)

           if server.name in qa_servers:

               server.ensure_line('/etc/profile','EXPORT RUBY_ENV=QA')

I know I can write modules to do this, but it'd be awesome to do away with the concept of cookbooks, and let me just write everything in a more straightforward language.

<comment><USER5> Yesterday I was playing with ansible, testing to migrate my already made across years scripts.

My vote for the one who puts here an elegant solution for something as simple as:

        ssh user@host sed -i '/FOO/ s/FOO*/BAR/' /etc/bla/bla-*

And a raw: command: or shell: does not count as elegant solution for the vote.

The first parts is easy, you just have to learn a new DSL because ansible ignores your .ssh/config.

The sed is easy to replace to with a lineinfile:

But... how can I iterate over the remote files?

I don't like my solution, is not elegant:

        - name: Get the list of remote files
          raw: printf '['; printf "'%s'," /etc/sysconfig/network-scripts/ifcfg-*; printf ']'
          register: p

        - name: Apply the change to the list of files
          lineinfile: dest={{ item }} regexp=^NETWORKING_IPV6 line='NETWORKING_IPV6=no'
          with_items: p.stdout

My impression in general, after my first weekend with ansible: great

But I see my old script to setup a daemon in a chroot, and I see "my" ansible version... and I don't know what to tell (the ansible version just multiplies the lines, in a much more verbose way, that finally looking at it, you have to think and concentrate much more, than looking at my old and direct .sh)

At the end... this is not new:

        ssh WORD < SCRIPT

Where WORD comes from your .ssh/config definitions (the inventory) and SCRIPT is up to you to define and organize properly.

But I wish users of my software where so happy first day as I'm with my ansible experience.

<comment><USER5> And other thing I've learn this weekend.

The documentation is great, but there is no "a reference", you have to read 5 or 6 different (long) pages to have an overview of what the DSL is, but the only reference is for the modules, not for the core.

You can search for ansible playbooks in sites like github, and... even if you will find a few which do what they say, you will find many "test" repos, and you will find that the 95% of the available code (no from ansibleworks, but by third parties) implement very poor deployments, without even following basic best practices or any security in mind.

I (as final user) would like a "cpan" or "rubygems" or whatever of ansible playbooks, more extended than the ansibleworks examples. Where people could share, search, vote, download (ansible get?), etc ansible playbooks.

Just suggestions.

<comment><USER3> Thanks for feedback.

I would suggest looking at github.com/ansible/ansible-examples for a fair amount of examples.

I think it's generally true of most systems that a lot of the community implemented content is suited to the needs of someone who wrote it.

As for content sharing, we might be working on something :) Stay tuned!

</comment></comment></comment></comment><comment><USER6> As someone who has written utilities to check for configuration changes presented by packages systems when they update, glossing over this issue is a bad idea.

Having a unified configuration that you can track and push is good, but if you are installing from RPM or DEB, you want to know if the package is pushing a new config itself, or providing a new config for review.

The utility I wrote looked for .rpmnew and .rpmsave save files and checked with a central repo for whether they were whitelisted (by MD5) or not. Anything not whitelisted resulted in mail being sent alerting admins. Along with an fairly comprehensive per-host auto-update exclude list (which I got yum-autoupdate patched upstream to allow), this allowed us to be fairly confident in allowing our 100+ boxes to auto update every day.

Without paying close attention to packages release notes, interesting things can come down from the maintainers, usually from them back-porting a fix from a later version (or a feature, if it's a RHEL point release).

I think configuration management is a good thing, but I'm not sure it's the best thing to be taught _first_ , unless there's mentors to work with. Some things you just won't think of until it's bit you in the ass, and have that bite be at small scale until you've figured it all out is probably a good thing.

<comment><USER7> To address just the package concern, it's worth noting that Ansible can pin packages to a particular version, by naming the version you want installed.

Then, even if a new package is pushed to the repo, you will not receive it (and will be notified by an error by subsequent runs if it's been manually updated) until you update the inventory file.

Many things in Ansible can be pinned in similar ways.

[http://www.ansibleworks.com/docs/modules.html#yum](http://www.ansibleworks.com/docs/modules.html#yum)

<comment><USER3> I'd also highly recommend maintaining a local mirror, regardless of your CM system.

Makes things faster and ensures even if you don't pin versions you are not going to get upstream surprises.

</comment></comment></comment><comment><USER8> A coworker and I needed to get an ElasticSearch server up using chef, and the whole time we were complaining that we wished we could just use shell scripts.

So, we spent a friday and came up with [http://fuckingshellscripts.org](http://fuckingshellscripts.org). At first it was just a parody, but then it started to get real after we found a lot of value in just using shell scripts for simple servers.

Granted, we now use ansible and it has been far easier to implement than chef!

<comment><USER9> Oh man I thought fuckingshellscripts.org was going to be like giveupandusetables.com (which is now down).

I want to just use fucking shell scripts to configure servers. But it's a gem too which I don't want to install.

</comment></comment><comment><USER10> I think your ansible example could be improved by removing all the names.

        - name: Ensure https support for apt is installed
          apt: pkg=apt-transport-https state=present

smells a little bit like:

        // add one to x
        x += 1;

Additionally, I would far rather see "apt: pkg=apt-transport-https state=present" in my logs than "Ensure https support for apt is installed"

<comment><AUTHOR> That's a great point. I initially didn't have comments for any of those code sections. However, most of my reviewers encouraged me to add the comments so it would be clearer what each step was doing for beginners.

<comment><USER10> In that case, you can use YAML comments rather than ansible names. It makes it much more clear that it's optional, and you get the actual code in the log rather than the name/comment.

<comment><USER3> Ansible actually encourages the use of the names because they show up as task headers.

These are especially valuable when managing a large number of hosts.

<comment><USER10> That's exactly why I actively discourage the use of names. I'd much rather see "apt: pkg=foo" than "Ensure foo is installed" in my logs. Especially when I have a large number of hosts.

</comment></comment></comment></comment></comment><comment><USER11> This is a bit OT because the article is about configuring servers, but I wonder if anyone has found CM systems like this helpful for maintaining their desktop or laptop system configurations?

Every few upgrades of Ubuntu I seem to get into a situation that I want or have to do a clean install, then waste time getting the new system back into a workable state. It would have to be pretty lightweight and intuitive for my purposes.

<comment><AUTHOR> Great question.

Github has a project called Boxen that does this for Mac OSX: [http://boxen.github.com/](http://boxen.github.com/)

Google uses their own Puppet solution for their developer workstations: [http://www.youtube.com/watch?v=YlKXRdSAZhY](http://www.youtube.com/watch?v=YlKXRdSAZhY)

Ansible will work great for this too - particularly if you're on Linux.

</comment></comment><comment><USER12> > Which method supports easily templating your configuration files?

But you don't actually use templating. You just copy the file over.

What do you do when you have to edit the configuration file? When it needs to be different on every machine for whatever reason (IPs to listen on, hostnames)? What is the smart way to do that automatically?

<comment><USER7> Templates and host variables.

Templates use the jinja2 templating engine, so variables are represented by `{{ variable_name }}`, and you can put variables (as well as defaults) into Ansible configs to set them to different values for different servers.

</comment></comment><comment><USER13> In my opinion, ansible only beats puppet here in ease of initial setup. I even find the equivalent puppet script for this task to be a tad bit clearer. But we're talking just syntax now. I only see now just how similar puppet and ansible (and perhaps chef too) are. What with the ensure'ing and all.

Puppet is a bit difficult to setup (not too much, mind you, it does its own key generating and being a PKI on first setup just fine, and you can run it from its own internal webserver until you have to go all "webscale"), but after that it hums along nicely. Haven't had too much complaining to do.

Except that they changed the string escaping rules somewhere in the 2.7.x branch, which debian of course pushed because it's in the same point release. That was fun.

<comment><USER14> Maybe it's me, but I found Puppet very difficult to get started with. To the point where I would happily use a less capable system that was easier to learn.

<comment><USER15> That's interesting. I was setting up a server the other day and wanted to document it in a repeatable way but, having used Chef and Anisble in the past made me not want to go through the hassle of setting up a whole "thing"...

So I looked through the Puppet docs for about 5 minutes and found I could just run "Puppet apply whatever.pp" on the server and got everything working in about 15 minutes. And I'd never used it before in my life. So for now, I'm quite impressed with the ease of Puppet.

Chef and Ansible both are really great for 80 to 90% of what I've needed to do in the past. But that last 10-20% is _really_ painful. It requires huge contortions, or poking through the source code so that you understand the details of the system so thoroughly that you can write an new module, or abuse the existing modules and bend them to your will. I suspect that, in the end, Puppet will have the same sorts of limitations as the others. But it did have a very nice way of setting things up that didn't require a whole infrastructure.

<comment><USER3> Hmm, I haven't heard that feedback before. I'd be very interested in hearing what the last 20% you found complicated was. Drop me an email at michael AT ansibleworks DOT com if you like.

</comment></comment></comment></comment><comment><USER16> This article doesn't do a very good job of stating it's thesis: The ansible version is no fewer lines than the shell script version; but requires you to understand ansible and how it works.

It doesn't seem preferable to me, from this example.

Note, I don't need to be convinced of the benefits of configuration management in terms of reproducibility and reliability. I'm just saying the OP's examples don't really make the case it suggests they make, of showing how ansible is so much easier than shell scripts. It does not appear to be.

<comment><USER3> I think Matt did a pretty good job of showing how they were at about the same level of complexity for a new audience, but one of the things you don't see is that

(A) there's error handling,

(B) the system will only run commands as needed

and of course using things like 'with_items' and 'notify' ends up making it a lot shorter.

But yeah, most of Hacker News already has a read on that :)

</comment></comment><comment><USER17> Does ansible have some sort of REPL so I can use it for both manual administration and automated? I use shellscripts for a lot of stuff because they're just bash one-offs with seniority.

<comment><USER18> There is an unofficial one: [https://github.com/dominis/ansible- shell](https://github.com/dominis/ansible-shell)

</comment></comment><comment><USER19> The important concept here is Reentrancy [1] and versioned code.

If the configuration is small enough it's easier to write a script in bash that approximates the re-entrancy well enough instead of having to bootstrap the configuration manager, distribute the description files and execute it. In fact a bash library could go a long way covering the scope of these tools.

[1]: [https://en.wikipedia.org/wiki/Reentrancy_%28computing%29](https://en.wikipedia.org/wiki/Reentrancy_%28computing%29)

</comment><comment><USER20> Can anyone discuss their experience with Ansible versus Chef + knife-solo?

I found Chef clumsy and hard to set up on its own (its central server requirement seems like it was designed just to support a business model), but with knife-solo it's extremely usable.

<comment><USER21> I've used both, it's similar but a main difference is that you kick ansible off from another (say your dev machine) which then ssh's in and does it's stuff, whilst knife-solo starts from the host.

<comment><USER22> > knife-solo starts from the host.

Huh? You run `knife solo cook example.com` on your local machine. It then sshs in and runs what it needs to. (Granted, it runs everything via chef-solo, but the user experience is running a command locally.)

<comment><USER21> Oh I used it where the host boots up and then it it runs solo on the local machine. So in your example it's similar.

</comment></comment></comment></comment><comment><USER23> What seems to be missing is _updating_ the nginx.conf with sed or something.

In the article, you're just copying a new magic configuration from somewhere vs. "proper" sed use (in reality, it can be a bit more than that) in the shell script.

<comment><AUTHOR> Initially I was using Ansible's `lineinfile` module to do exactly that. It's pretty trivial to do if you want to compare true Apples to Apples. Here's an article with some examples: [http://fabian-affolter.ch/blog/the-lineinfile- module-of-ansi...](http://fabian-affolter.ch/blog/the-lineinfile-module-of- ansible/)

However, I wanted to show the actual process I went through. Editing the file in place seemed silly to do with Ansible, so I went with putting the config file in version control and copying it over. That also had the benefit of showing how Ansible encourages better practices than shell scripts.

Of course, that's totally subjective, so for some folks that use shell scripts, they may already know to put their config files in version control. However, in practice, I've not seen that be the case.

<comment><USER24> Also worth noting, ansible comes with a 'template' module which allows you to generate custom files with variables.

</comment></comment></comment><comment><USER25> The title of this article is really tilting. Does anyone defend shell scripts anymore?</comment>


Introducing the Facebook Card, a New Type of Gift Card - <AUTHOR> http://newsroom.fb.com/News/569/Introducing-the-Facebook-Card-a-New-Type-of-Gift-Card

<comment><USER2> Why would I want to use this? It will result in Facebook tracking more of my (or the benefactor of my gift's) movements, and then selling that info (or letting it leak out via sleazy apps that steal all my info)

Is this solving any problem or filling any hole in the market? Of course it's filling facebook's data hole in that they can't currently track what I buy. I'll keep that between myself, the retailer, and my bank. Thanks anyway.

<comment><USER3> Example: If you have a friend who likes Jamba Juice, and you wanted to get the person a gift card.

Are you going to spend the time to actually find a Jamba Juice and go there to buy a gift card? Or are you going to just click "buy as a gift for Friend" on Facebook?

Another option is to buy the gift card at another store, but then you're just filling Safeway's data hole or Target's data hole instead of Facebook's. Is that better?

<comment><USER4> Seriously who buys gift cards for a shop that sells drinks?

More importantly - a gift card in a shop can be bought with cash if you choose, and even if I used a credit card, my bank doesn't show me ads because I shopped somewhere

<comment><USER5>
      > Seriously who buys gift cards for a shop that sells drinks?

I had to re-read that several times, trying to decide if your 'Seriously' was seriously serious or not...

<http://www.statisticbrain.com/starbucks-company-statistics/>

      > Starbucks Company Statistics
      >  Year  Value of Gift Card Activations
      >  2011  $820,500,000

<comment><USER4> Oh of course I forgot we're talking about Americans.

I should have asked what sane person buys a gift card for a shop that sells drinks.

<comment><USER6> Jamba Juice is one thing because it isn't on every street corner, whereas buying Starbucks cards for people you know spend money on coffee every morning is not a bad investment. Furthermore, with Starbucks' cards, it allows you to start redeeming points for more drinks and gives you incentive to keep re- upping the value to earn those points. I get a free drink/food item every two weeks from what started as a gift card that turned into a gold card. Do I have a consumption problem? Sure. But it was a benefit to my already-shitty lifestyle and I can't complain.

</comment></comment></comment></comment></comment></comment><comment><USER7> I just don't get gift cards. Why would I give someone 20£ and then force them to spend them in a particular shop, rather than giving them cash or transferring money through the bank? It is a honest question, I've never given or received a gift card, I might just be missing something obvious.

<comment><USER8> "Why would I give someone 20 and then force them to spend them in a particular shop"

Why _wouldn't_ you do that, if the circumstances suggested it? It's a way of giving someone some freedom in choosing their gift, while restricting it to a range.

Maybe I want to buy someone a really nice suit, but I know they'd never do it themselves; they just can't bring themselves to spend a lot of money on a nice suit - they permanently dress in cheap clothes from discount stores. If I give them cash, they feel guilty for spending it on a suit, and also guilty if they _don't_ do that, because they know I wanted them to spend it on a nice suit. Gift voucher ahoy. I'm sure you can imagine other circumstances.

Others that leap to my mind are; forcing someone to buy books instead of blowing it on alcohol and skateboards; making it harder for someone to buy drugs with it (there are always ways to launder gift vouchers, but the discount can be huge); giving gift vouchers for some place they really love as a way of demonstrating that you've actually thought about it.

When someone gives me cash, it suggests to me that they haven't put in any effort. I'd rather they got me something that cost a fiver but they actually know I like, than giving me a twenty. I already have some money and from the point where I started working full-time, unless someone is going to give me a life-changing amount of money, they might as well not bother. A well thought- out gift-voucher can be a half-way house.

Furthermore, when you give someone money (unless you give a life-changing amount), it just goes into their pocket with the rest of their money. Some will go on an electricity bill, some will go on food, some will be train fare, it'll all just disappear in things they were going to do anyway. Unless they were living on the breadline, you've made no difference - there is nothing that they have, or did, that was because you gave them some money. You might as well have not bothered. Money - it's the gift people don't even notice.

<comment><USER9> "When someone gives me cash, it suggests to me that they haven't put in any effort."

Why would you assume someone has to make more than the effort of working for a pay check, and then giving you some of that hard earned cash to do with as you please?

But then you go on to say; "unless someone is going to give me a life-changing amount of money, they might as well not bother." .. what the hell, dude?

<comment><USER8> "Why would you assume someone has to make more than the effort of working for a pay check, and then giving you some of that hard earned cash to do with as you please?"

Did they get up in the morning thinking "today I'm going to work hard so I can give that guy a nice present"? No. At some point they thought they'd better give me something, and reached for the easiest, most convenient thing they had. Some money. The bare minimum of thought went into it. Why do I want more than the bare minimum of thought? Because that's what friends do. More than the bare minimum. I spend hours and hours, sometimes spread over several weeks, thinking about and finding great gifts for people, because I genuinely like seeing my friends made happy by unexpectedly receiving something they'll really get a lot of pleasure out of.

" "unless someone is going to give me a life-changing amount of money, they might as well not bother." .. what the hell, dude?"

What? What's not to understand? Someone gives me a twenty. I already have a twenty. I have more than one. If there was something I wanted to buy with it, I already would have. Unless I'm living at the point where I am right on the breadline, one grocery bill from poverty, I won't even notice it (as above, it'll go into the pot marked "money" and just go on some bill or some tax or the rent or whatever). Sad but true; I have made enough to comfortably pay my bills with some left over. If they had stopped off somewhere and spent a five on something they really know I'd like, something that required them to think and spend some time, it would show real effort on my behalf. Sometimes the clichés are true; it's the thought that counts.

<comment><USER4> So giving you $50 cash is lazy but buying you $50 of fucking juice is a well thought out present? Or giving you $50 to spend in a department store is better than $50 cash you can spend _anywhere_. It isn't more personal its just more restricted.

Gift cards are like food stamps for middle class people. You may as well include a note saying "now don't you spend this on drugs".

</comment></comment></comment></comment></comment><comment><USER10> Does Facebook really drive that kind of commerce? Micropayments on Facebook games is one thing, but I remember a time when you could buy little badges and icons for your friends to place on their wall. That didn't last too long.

Not to mention the hum drum partners FB is pairing with. Olive Garden? Really? Facebook's new monetization strategy is to do what the checkout lane at my local supermarket has been doing for years.

<comment><USER11> _> Facebook's new monetization strategy is to do what the checkout lane at my local supermarket has been doing for years._

If you put it that way Google's monetization strategy is what Yellow Pages has been doing for decades. Does't seem to be working that bad so far.

</comment></comment><comment><USER12> I can barely trust Facebook when it comes to privacy settings. Personally, I'd never mix finances with Facebook.

<comment><AUTHOR> By the converse opinion, if you actually set the privacy settings on Facebook, and Google for that matter, to your comfort level, your data is probably more secure than if you weren't using Facebook or Google etc.

<comment><USER13> I think by now it is obvious that issue is not about privacy anymore rather how these gigantic companies are "using" your data to their advantage, and not really yours!

</comment></comment></comment><comment><USER6> I can totally see the desire for multi-vendor gift cards, but I'd almost rather see a company like Simple handle that, not a brand synonymous with shady practices and the rest of my personal data as-is.

<comment><USER14> Amex and Visa do this already. Facebook is just the entry point for Discover, the least-accepted-credit-card in America.

<comment><USER6> Ah right, I didn't think about that. Chase also has the Liquid card now, but it costs a monthly fee.

</comment></comment></comment><comment><USER15> It looks like this is just a prepaid credit card with dedicated balances for each merchant. While I'm sure Facebook has buy-in from the merchants (as they are using their logo and other brand marks), in theory Facebook could offer gift cards for arbitrary merchants. At POS Facebook just uses the merchant identifier to determine which balance to approve funds and subtract from -- aside from that, it works like a normal prepaid credit card.

<comment><USER16> It doesn't appear that this is the case. This is more like a multi-gift-card (not sure of any technical term for it) than a pre-paid credit card. From all I can see, you can't use it to make purchases at any merchants other than the ones which have balances on the card. This is much like the Verizon Visa Gift Card that was being given out when you would sign up for certain FIOS services. It was a Visa credit card, except it was not able to be used at any Visa accepting merchant, but only Verizon approved merchants. Hardly a normal pre-paid credit card.

<comment><USER15> That's my point... from the merchant standpoint there is no additional integration required... they just process it as a credit card. Facebook limits the spend based on the merchant identifier that gets sent to them from the POS. Basically they've created a multi-gift-card using existing credit card technology without the partners needing to update their POS to support it.

</comment></comment></comment><comment><USER17> I think it's a smart move. I doubt this will directly be a major revenue stream. But there's more at play here. FB has been trying to figure out ways to track and collect retail data for a while. Remember beacon? This seems like an interesting way to start understanding what you buy and where. Thus making advertising even more efficient.

</comment><comment><USER3> _Beginning today, people can give their friends gifts to Jamba Juice, Olive Garden, Sephora, and Target all on one reusable gift card from Facebook._

Looking at their initial retail partners, they have a beverage store, restaurant, cosmetics store(?), and big-box retailer. For contrast, they aren't starting with Starbucks, Cheesecake Factory, CVS, and Sears.

</comment><comment><USER18> I love it. This may very well be the first monetization attempt I can tolerate from Facebook: it's (finally) a win-win scenario for all parties involved, and it makes a superb use of both the social graph and the fact that nowadays every aunt, uncle and nephew have an account on Facebook. Brilliant.

Looking forward to try it here in Canada.

</comment><comment><USER19> So will FB (eventually) make a timeline post on my behalf when I buy coffee?</comment>


Can a Shorter Workweek Make People Happier? - Bella-Xiang https://www.visualcapitalist.com/shorter-workweek-make-people-happier/ <comment><AUTHOR> It's not about making people "happy." It's about giving them more time to pursue whatever they want, be it happiness, profit, or world dominance. It's also about accommodating the increasing disconnect between number of workers available and meaningful jobs for those workers.

</comment><comment><USER2> I don't think the number of days (less or more) is what will make the different. As humans we are almost always going to complain about wanting more or less of something.

I know that for me the things that make me happier are:

\- more efficient use of time \- more effective processes (very much tied to the above) \- percentage of time dedicated within the workweek to personal projects that might be far removed from the actual job or have a very long- term upside \- more focus on the output rather than how/when the job got done. Note: I'm absolutely not saying here that all means justify the end.</comment>


Everyone should learn [about] programming - <AUTHOR> http://swizec.com/blog/everyone-should-learn-about-programming/swizec/3608

<comment><USER2> The entire article was all worth the read only because of the last line...

"And hey, startup opportunity! You now have somebody with a real problem looking for a real solution! Hooray."

:)</comment>