Upstream vendors and why they can be harmful - <AUTHOR> http://marc.info/?l=openbsd-tech&m=135220552521529&w=2

<comment><USER2> This submission won't make any sense without a little bit of background. (The comments here at the moment are all predictably confused.)

Start here: <http://lwn.net/Articles/520892/>

Core parts of Gnome (and probably lots of other Linux-y software, I haven't been following all of it) are all moving to require systemd. Systemd certainly promises a lot of advantages, like better handling of removable devices (and more: <https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530>), but it is also replacing the tried-and-trusted rc approach. OpenBSD leaders in particular are concerned about systemd from a security standpoint; it has a lot of code that runs as root, it is big and unwieldy and the documentation is a mess.

So, not only were the OpenBSD developers faced with either auditing the entire systemd code base -- and then doing it again every time there's a new release -- or attempting to re-implement it in a compatible way, now they're also staring down the very short barrel of a nasty gun in which some really big stuff is going to stop working if they don't deal with it.

It's a real ugly situation, and OpenBSD really doesn't have the resources to spare to deal with this kind of nonsense. I wouldn't be surprised if this mess ends up tying up a couple of their core developers at an upcoming hackathon, where they could instead be working on something more useful than having to replace a huge part of the system that was working just fine up until Linux decided to throw it out. (Obviously there are plenty of people that would argue it wasn't "working just fine", either because they have specific knowledge about it or because "otherwise we wouldn't have needed systemd". That's not sufficient justification for forcing other developers to waste tremendous amounts of effort to re-work what was already working for them.)

Personally, I'm not a huge fan of the switch to systemd. I _liked_ rc scripts. I've cobbled together my own rc daemon scripts from time to time; I'm not sure how that will work with systemd. I'm also seeing lots of ugly and persistent problems in NetworkMangler and whatever they're using for core audio these days; I'm a little gobsmacked that, rather than fixing those problems, some people decided to replace the init system.

<comment><USER3> I don't understand why systemd is suddenly such a hard requirement: it suggests that the Gnome developers are simply punching through the abstraction layer provided by dbus for reasons of convenience. If some part of Gnome needs a system service, it requests it via dbus and parses the response. How that service is delivered ought to be irrelevant.

Since systemd _is_ supposed to offer all its services via dbus, is the problem really "we don't want to implement all these services that a modern desktop needs". OpenBSD et al could offer a dbus layer that implements the same set of services, but they don't want (or have the manpower) to do so. In which case, I'm not really sure they have a leg to stand on: the things systemd offers really are important for a modern well integrated desktop (or any other system for that matter) and they weren't well served by initscripts. OpenBSD is free to implement a service that offers the same dbus interfaces whenever they want, but complaining about Linuxisms is perhaps a little rich: if you want your system to remain stuck in the early 1990s then that's fine, but you can't really expect the rest of the world to hang around waiting for you to catch up.

<comment><USER3> NB If the answer to "why can't you write dbus interfaces" is "we'd love to, but the Gnome developers keep changing the interfaces every minor point release" then that's probably a valid retort...

</comment></comment></comment><comment><USER4> I agree entirely with the sentiment here. If you've ever had to piece together something external to your distribution you will know the pain involved. This is amplified considerably if you pick a BSD-related operating system and for no good reason.

The Linux kernel itself is a remarkably stable system as far as ABI/API is concerned (Linus you rock here), but the packages gyrating around it are completely impossibly unstable and unreliable.

A fine example of this is trying to get an SSTP client working with NetworkManager recently. The whole NetworkManager VPN thing is an epic pile of hacks with bits of UI and bits of backend sticking out all over the place. If you're using Debian stable for example, there is no chance in hell you can get a working configuration unless you go and fix the numerous broken interfaces all over the place manually and arguing with pkg-config and literally hundreds of dependencies. How the fuck this ever even worked to start with I don't know. There are massive API changes with minor versions of packages all through NetworkManager and Gnome, which is just wrong.

The underlying issue is simply shitty engineering from a large body of open source projects who don't care about upstream or doing their job properly. To name and shame: The _entire_ Gnome project, just about anything Ubuntu have chucked out, the _entire_ KDE project post KDE2.

It's utterly frustrating. I wish they _did_ take a more BSD approach, which is conservative engineering i.e. think about it, get it right and leave it.

For all the people here whinging about innovation, waah waah, ship old versions etc, I doubt you've actually had to deal with these issues or build a project on top of them. There seems to be a large detachment from reality here.

As an example to back my point up, one of the reasons Windows is so damn popular is that the API is _incredibly_ stable and software written in the mid-90s still works fine on current versions without a recompilation or any API changes. A two week old build of NetworkManager probably will break all the VPN providers...

<comment><USER5> _The Linux kernel itself is a remarkably stable system as far as ABI/API is concerned_

You're joking, right? There have been cases where ABIs have been broken by security patches, and users have been told that they have to choose between having a secure system and being able to use their third-party binary drivers.

(And yes, I understand the arguments about how binary drivers are evil; but I don't think users should be used as pawns in that fight.)

<comment><USER6> He was probably talking of the user-space ABI/API. Drivers are internal to the kernel (or should be) and Linux never made a claim that those APIs where going to be stable.

<comment><USER4> Yes that is correct.

</comment></comment></comment></comment><comment><USER7> > Either you're a modern linux with pulseaudio and pam and systemd, or you're > dying. So much for the pionneer spirit of opensource, where you were free to > innovate and do cool things, and more or less have interesting software able > to run on your machine...

What a weird doublespeak paragraph. By "innovate and do cool things," the author seems to mean "ship, and rely on, old versions of software."

<comment><USER8> I think he's complaining about the "Linux-centrism" of some projects.

What I find ironic is that those Linux focused projects are turning more like BSD: a tightly coupled system.

If I want my app to work best with X and I need to interact with some stuff that it's only available on X, that's it. I may provide an alternate way of doing things, but I may not.

For example: I may use DBus to speak with NM to see if I the system has network connectivity, but what if DBus or NM are not available? Some time ago you would put effort on that possibility, now you may not because... DBus and NM are everywhere!

That's what is changing I think, although I'm not sure if Espie means exactly that.

In some cases it's the "brand" thing I can't understand, like "only for Ubuntu" that started about 2-3 years ago.

<comment><USER9> > Some time ago you would put effort on that possibility, now you may not > because... DBus and NM are everywhere!

Which sounds like a good thing. People have put in a lot of effort on things like DBus and NM, so that applications can use a consistent, reliable API. That's rather a waste if every application author still has to handle the case when they're missing. They're valuable precisely because we can build on top of them.

I'm slightly playing devil's advocate, but that's actually pretty close to my real view.

<comment><USER8> Having used DBus in a couple of projects, the "consistent, reliable" part of your comment made me chuckle :)

I agree with you. Having APIs makes everything easier and it means developers building on top of them can focus on more productive stuff.

In fact I think freedesktop.org should be more relevant.

</comment></comment></comment></comment><comment><USER10> The Linux Desktop can't stand still to accommodate some minor platform. I understand that a move to systemd and in the future to wayland will have problematic consequences for BSD support. But the changes are made for good reasons and to bring the Linux and Free Software Desktop forward.

Systemd is much better for Desktop uses. The major reason is that it is fully designed to support hotplug. Which is something you have to constantly deal with on Desktop/Laptop systems. Disks are plugged in, Network connection isn't ready, and so on. It is also much faster and has a lot of other nice features. The lack of systemd support in *Ubuntu might be the reason for me to switch to another distribution for my Desktop.

Wayland finally allows us to get rid off all the legacy crap we have to carry around with X11. There is a reason why it is developed by the Xorg devs.

Pulseaudio had its reasons as well. Such as having useful support for Bluetooth- or USB-audio. Per-application audio settings and so on.

Of course you can argue with certain details in certain implementations. But I don't think that we can argue about the problems those solutions solve. Maybe you are happy with the setup you've been using since the 90s. But for most people the times are changing.

It is certainly sad that the BSDs don't have the manpower to keep up. However we can not expect the Linux Desktop to stand still because of them. The Linux Desktop itself lacks manpower and is fighting an uphill battle. Supporting minor systems will only drag it down.

<comment><USER11> > Systemd is much better for Desktop uses. The major reason is that it is > fully designed to support hotplug.

This is exactly why upstart was invented, long before systemd existed.

> Which is something you have to constantly deal with on Desktop/Laptop > systems. Disks are plugged in, Network connection isn't ready, and so on. It > is also much faster and has a lot of other nice features. The lack of > systemd support in *Ubuntu might be the reason for me to switch to another > distribution for my Desktop.

Ubuntu uses upstart, which handles everything that you have specified just fine. You may well have a good reason to switch away, but you have failed to state your case here.

<comment><USER12> > This is exactly why upstart was invented, long before systemd existed.

Except that upstart didn't deliver too much, unlike systemd. Fedora used upstart (RHEL6 still does) and it wasn't very different from the traditional SysV init. I also wasn't able to figure out how to use it to its full potential, it looked too complicated. On the other hand perhaps I'm biased because Lennart provided a series on systemd for administrators.

<comment><USER11> There's a pretty comprehensive guide here: <http://upstart.ubuntu.com/cookbook/>

</comment></comment></comment></comment><comment><USER13> The development within Linux is going much quicker than anything else can keep up. Within GNOME only very recently we got some non-Linux using contributors. Portability just for portabilities sake is not a goal anymore.

This is somewhat ironic, as excluding OpenBSD feels way too similar to how Linux is/was excluded in favour of Windows. But if almost all the people spend their time to make their Linux distro better, then this seems like a natural thing to occur.

</comment><comment><USER14> Hmmm... well I certainly see the problem from 'their end' in that they find themselves 'incompatible' with external projects on which they have relied on since they are nowadays increasingly being developed with 'Linux in mind'.

However it's also hard to fault the obvious urge from Linux and the surrounding Linux-oriented ecosystem of making sure components integrate better so the result is a 'full system' which takes advantage of advancements made to the Linux kernel and it's surrounding core components.

I can't say one is right and one is wrong, I guess it's all about which side of the fence you're on.

</comment><comment><USER15> When OpenBSD was pissed off by proprietary HSRP protocol designed by Cisco, they decided to implement their own protocol (not compatible with HSRP) and use the same IP protocol number 114 without IANA approval. [http://en.wikipedia.org/wiki/Common_Address_Redundancy_Proto...](http://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol) This created a serious mess for system administrators and gives a good example of how to handle compatibility and standards related issues ;)

<comment><USER16> I guess IANA should have given them a protocol number like they requested then, instead of playing politics because cisco employees run the organization.

<comment><USER15> Sure, but OpenBSD could have chosen some reasonably safe number that would not be in obvious conflict with Cisco equipment and would make users life easier. Instead they decided to have a childish revenge on Cisco.

<comment><USER16> It didn't make our life any harder, and using a different number wouldn't make our life any easier. We use cisco, juniper and openbsd, this caused exactly zero problems.

<comment><USER15> I'm sorry if this isn't accurate assessment. I based it on the ACM column: <http://queue.acm.org/detail.cfm?id=2090149>

<comment><USER16> Yeah, that is a hilarious attempt to misrepresent the situation. Notice how he pretends they did it "to strike back", when they actually did exactly what he wants (try to get a number from IANA) and they refused to give them one because "that's just VRRP but different, it doesn't deserve its own number". The right choice was taken away from them, all they could do is use a number that is either used already, or will be handed out later. They chose the least bad option of using the number of VRRP, which IANA claimed they were too similar to.

</comment></comment></comment></comment></comment></comment><comment><USER17> Note that some of these things are grumbled about within the Linux community too - there's plenty of complaining about pulseaudio, and systemd is very unlikely to ever be universally used by Linux distributions.

</comment><comment><USER18> Starting from small things, it would also be great to stop using #!/bin/bash in scripts for no apparent reason (hint: "it's my default shell" is not a good reason.)

<comment><USER3> I'd far rather people did that than used #!/bin/sh and assumed that sh was bash!

<comment><USER16> It isn't a choice between "do it wrong A" and "do it wrong B". There are a whole host of options, one of which is "do it right". Relying on a non- standard shell to be in /bin is bad, relying on non-standard shell extensions to be in the standard shell is also bad. So either use the standard shell as the standard shell, or use whatever nonstandard shell you want by calling env to find it.

</comment></comment></comment><comment><USER19> I would love to see a group of hackers get together to create a real (i.e. not a weak ARM device) computer and operating system, for profit _, but open source. It seems like people have mostly given up on this notion, as if its impossible to create a competing device. In the 70s/80s, a few people launched brands like Apple, Microsoft, and Amiga; I know things are harder now but it is far from impossible.

_ Why for profit? So that people have both an incentive and means to work on the product fulltime.

<comment><USER20> Indeed. What we need is a yet to be created firm with the engineering ethos of Trolltech attacking the problem that Apple is right now.

</comment></comment><comment><USER21> Wouldn't it be more appropriate to talk about LinuxDesktopism?

There I see part of an explanation regarding the opposite market shares between the server/HPC and desktop worlds.

</comment><comment><USER22> I'm a 100% Linux user

I find systemd & others are hurting Linux as much as it hurts BSDs.

In fact, just look at the ArchLinux forums, its FILLED with systemd issues. And most people know by now about the "disable pulseaudio, use pure alsa" trick to solve "all Linux audio issues". Heh.

</comment><comment><USER23> The case _for_ Linuxism is that Linux has the underlying tools applications require to deliver the user experience users want, and if OpenBSD (and this is from an OpenBSD list) wants to run those applications it should provide the same tools.

A _better_ case against Linuxism is that portability encourages modularity, which is good for reasons far beyond portability. Having to do some things in a different module because they can't be done the same way on all systems encourages you to separate concerns, which leads to code that's easier to reason about and, therefore, less likely to be buggy.

The historical perspective is "You think this is bad, sonny, be glad you're not trying to convince people to play nice with Eunice." (Eunice was a Unix- like environment running on VAX/VMS.)</comment>


The Rust compiler is still getting faster - <AUTHOR> https://blog.mozilla.org/nnethercote/2019/07/25/the-rust-compiler-is-still-getting-faster/ <comment><USER2> The rust compiler now has features that few or none C and C++ compilers have: incremental compilation within a single translation unit, pipelined compilation, multi-threaded and lazy query-based compilation, ...

Implementing each of these features have required whole program refactorings in a large-scale codebase performed by few individuals while hundreds of other developers where simultaneously evolving the software and implementing new features.

Having been a C++ programmer for over 10 years, none of these refactorings would have payed off in C++ because of how time consuming it would have been to track all bugs introduced by them.

Yet they do pay off in Rust because of my favourite Rust feature: the ability to refactor large-scale software without breaking anything: if a non- functional change compiles, "it works" for some definition of "works" that's much better than what most other languages give you (no memory unsafety, no data-races, no segfaults...).

Very few programming languages have this feature, and no low-level programming language except for Rust has it.

Software design is not an upfront-only task, and Rust let's you iterate on software design as you better understand the problem domain or the constraints and requirements change without having to rewrite things from scratch.

<comment><USER3> Visual C++ is part of those few.

Rust is still far from Delphi, Eiffel, .NET Native experience though.

Although it is great that it keeps improving.

<comment><USER2> Is there a blog post about Visual C++ being multi-threaded end-to-end ? (e.g. doing parsing, type-checking, etc. of a single TU in parallel using all cores ?)

That would be super interesting to read because it is mainly a C++ compiler and some C++ features like two-phase lookup and macros make it quite hard to do things in parallel. You have to do things in a certain order but I suppose that if its query-based as well it will work.

The only option I know is /CGTHREADS but that only uses multiple-threads for optimizations and code generation which is something that the Rust compiler has been able to do for a very long time (e.g. there these are called codegen- units and LLVM supports these so it is quite trivial for a frontend to do so as well).

<comment><USER4> As the documentation says: "The /MP (Build with Multiple Processes) compiler flag specifies the number of cl.exe processes that simultaneously compile the source files. The /cgthreads option specifies the number of threads used by each cl.exe process." I've never used /CGTHREADS but /MP is working well (except for the precompliled header file).

<comment><USER5> That's for different source files though, right? Try having a 10Mb auto- generated C++ file, see how fast it compiles, regardless how powerful your computer is.

<comment><USER2> No need to autogenerate anything: expand all headerfiles into a .cpp file, and you easily end up with > 10Mb files.

Visual C++ pre-compiled headers is quite amazing and works really great, avoiding this almost completely.

</comment></comment></comment></comment></comment></comment><comment><USER6> This is great! Many dev hours are spend waiting for the compiler, every second counts!

The second order effects are even worse. After a minute, the programmer will start thinking about other things, running flow.

If compiles regularly take 5min, devs will leave their desks (and honestly, who can blame them for it).

<comment><USER2> I just use `cargo watch -x test -d 5` to run all my tests after I pause modifying code for 5 seconds.

My editor (emacs) uses `cargo watch -x check -d 0.5` to run `cargo check` (which is blazing fast for incremental edits) to type check all the code and show "red squiggles" with the error messages inline.

So my interactive workflow with Rust is only edit-"type check"-edit-"type check" where "type check" takes often less than a second.

Asynchronously in the background, the whole test suite (or the part that makes sense for what I'm doing) is always being run. So if a test actually fails to run, I discover that a little bit later.

I don't know any language for which running all tests happens instantaneously. With Rust, if anything, I write less tests because there are many things I don't need to check (e.g. what happens on out-of-bounds accesses).

This is the best workflow I've ever had. In C++ there was no way to only run type checking, so one always had to run the full compilation and linking stages, where linking took a long time, and you could get template instantiation errors quite late, and well, linking errors. I don't think I've ever seen a Rust linking error. They probably do happen, but in C++ they happen relatively often (at least once per week).

<comment><USER7> > In C++ there was no way to only run type checking

gcc has -fsyntax-only. Despite the option name, this also includes type checking and template instantiation. AFAIK it reports all compiler errors, though it skips some warnings that are computed by the optimizer (e.g. -Wuninitialized).

<comment><USER2> Is there an easy way to tell CMake or Makefiles to use it ?

I never invoke clang or gcc directly. When using cargo, I use `cargo check` instead of `cargo build`. But in C or C++ depending on the project `make check` might not exist, or it might build all tests and run them, or do something else entirely like checking the formatting using clang-format.

<comment><USER8> > \- CMake > \- Easy

Pick one. I'm sure there is though.

It wouldn't be hard with make but then again I'm much more familiar with it than cmake.

<comment><USER2> So I manage to get it to work in the command line using `CXXFLAGS="$CXXFLAGS -fsyntax-check" cmake ... && make` !

<comment><USER8> One issue with that is that is, unless there is magic handling of the flag in cmake, it might still attempt (and fail) to run the linking stages. You might need custom targets jut for this.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Faster compiler is nice, but you know what's faster? Not having to compile anything. I'm also looking forward to crates.io serving precompiled crates ([https://www.ncameron.org/blog/cargo- in-2019/](https://www.ncameron.org/blog/cargo-in-2019/))

<comment><USER10> I'm a Rust noob but I think skunkopalypse was making some good points. I wish people didn't vote down his/her comment to death and actually replied to it so I could learn why he/she wasn't right.

<comment><USER11> I too think that precompiling crates won't really solve the problem.

If you compare the compiled artifact (rlib) of a crate with the source code, you'll quickly see that the compiled artifact is much larger than the source code. libglutin-0c732c31a1d003fb.rlib has 8.1 MB while glutin-0.22.0-alpha1.crate has 53 KB.

Most people have shitty internet. And often it's nothing you can do about it because you have shitty ISPs. You can buy a computer with good CPUs and those are usually cheaper in comparison than good internet for a year, at least in many rural areas in the US. It's not just the US, some other countries have it even worse.

Now of course if you have good internet and a bad CPU it's a good deal, so there should definitely be an option to use it, maybe even with autodetection. But I think cargo has too much dependency on the internet, not too little. There should be no manual input required to turn off precompiled crates downloads if it is faster to compile the crates locally.

</comment></comment></comment><comment><USER12> Does LLVM still take up much of the overall time spent by the Rust compiler? I was thinking of getting involved over there as the most effective way to make speed-ups happen.

<comment><USER13> I remember reading that it does, but because the LLVM IR generated by rustc is verbose. If less IR was generated, LLVM would have less work to do.

<comment><USER14> I think that's one of the eventual purposes of MIR (by both optimising Rust upstream from the LLVM IR generation and having a much simpler language to generate IR for), but I don't know if there's been work towards that yet.

</comment></comment></comment><comment><USER15> I wish compiling the Rust compiler itself was faster. It literally takes days to compile on my old laptop.

<comment><USER16> Wait, what language were you compiling it on?

<comment><USER17> Rust has been bootstrapped for a long time now.

</comment></comment></comment><comment><USER18> Maybe they should make compiling the Rust compiler faster. Right now it takes longer and uses more CPU and memory than compiling a whole LLVM toolchain, then using that toolchain to compile a whole kernel and OS.

<comment><USER19> Compiling the Rust compiler also requires compiling LLVM, so by definition it will always take longer than that.</comment></comment>


Show HN: Awesome Ideation Tools - <AUTHOR> https://github.com/zazaalaza/awesome-ideation-tools <comment><USER2> Thanks for an excellent curated list.

<comment><AUTHOR> You're welcome.

</comment></comment><comment><USER3> Like yout collection!</comment>


The Perfect French Baguette - <AUTHOR> http://www.bbc.com/travel/story/20190825-the-perfect-french-baguette <comment><USER2> > In addition to winning this illustrious competition, Bouattour and M'Seddi > have a few other things in common. Both forewent the traditional trade > school that many aspiring French bakers enter at age 16. Both have been > professional bakers for less than a decade (as has this year's winner, > former engineer Fabrice Leroy). And both are first-generation Frenchmen with > what Bouattour euphemistically dubs 'origins': family backgrounds from > elsewhere – or in their cases, Tunisia.

> "I stopped thinking of myself as a foreigner a long time ago, but my origins > make me the person I am today," he said. "We all start with the same tools, > the same teachers, but some people are going to understand things > differently. That has nothing to do with origins; that's just talent."

For all the rhetoric on the right about how people from other cultures are not "suitable" for "western" countries - some of the proudest citizens and torch- carriers for tradition, are foreigners.

It also absolutely works both ways - Australia was virulently anti Italian and Greek in the 50s and 60s. Now we almost couldn't imagine brunch without espresso and feta on our smashed avocado. The diversity made us better.

<comment><USER3> What I've always found interesting as a Frenchman living in North Americ, is that there's no real equivalent to "black american" or "afro American" or "hispano American" in French. The closest you'll find is "of Tunisian origins", but that's usually left out, and not really the same.

The "official" results[0] don't mention anything about his origins. The local press[1] does say his parents are from Tunisia, but only after introducing him as a Parisian. The right national press[2][3] does mention that he is... a chemist, which seems more relevant to the story than the country in which his parent were born.

Surely this is an anecdote, but it does match the general observation I've made. (although be sure that would he have killed a person rather than cooked a baguette, his origins would be of the utmost importance for the story telling).

[0] [https://www.paris.fr/pages/goutez-et-choisissez-la- meilleure...](https://www.paris.fr/pages/goutez-et-choisissez-la-meilleure- baguette-de-paris-6640) [1] [http://www.leparisien.fr/paris-75/paris-il-fait- la-meilleure...](http://www.leparisien.fr/paris-75/paris-il-fait-la-meilleure- baguette-de-tradition-parisienne-13-04-2018-7662258.php) [2] [https://www.bfmtv.com/societe/la-meilleure-baguette-de- paris...](https://www.bfmtv.com/societe/la-meilleure-baguette-de-paris-se- trouve-dans-le-14e-arrondissement-1418199.html) [3] [http://www.lefigaro.fr/sortir- paris/2018/04/13/30004-2018041...](http://www.lefigaro.fr/sortir- paris/2018/04/13/30004-20180413ARTFIG00155-la-meilleure-baguette-de-paris-se- trouve-dans-le-xive.php)

<comment><USER4> The downside of this French attitude of everyone being "just French" is that the earlier diversity of identities/languages has also been largely homogenised. Think Alsacian, Languedoc, etc.

The effect reaches well beyond France: as other countries fell in love with the model, they went after their own historical ethnic/linguistic minorities with the same determination throughout the 20th century.

<comment> ur-whale >has also been largely homogenised

You say it like it's a bad thing.

<comment><USER5> why is it a good thing. For Alsace, the goal of the french state was clear: kill the alsatian culture so that alsatians do not side anymore with the germans. This began by prohibiting children to speak alsatian. Now, the new generation cannot speak it anymore and cannot understand their neighbours (Luxembourg, Germany, Switzerland). They have to learn German in school, and they are not particularly good at it. It is a shame, as it would be a nice advantage for them in the current EU.

The same happened for other regions (Bretagne, Languedoc, Corsica, Pays basque).

<comment><USER6> I believe what ur-whale is saying is that cultural homogenization, is often seen as bad things for the short term for people that have to endure it, but relatively for the long term it creates more homogeneous region with a shared culture.

For example, the Roman Empire destroyed or assimilated hundreds of smaller culture, but it also have the long term effect of creating a common ancestor culture for most of Europe.

</comment></comment></comment></comment></comment></comment><comment><USER7> It's interesting that the modern baguette is such a symbol, as it's a product of the Industrial Age (steam driven ovens) and its introduction alsmost drove artisanal breads from the market over a period of 50 years (until, it seems, Poilâne revived it. Of course people continued to produce non-baguettes all along, they just weren't iconic or common).

So now there's a lovely assortment of brads available again...and with all that choice I still continue to enjoy a humble baguette as well.

<comment><USER8> > It's interesting that the modern baguette is such a symbol, as it's a > product of the Industrial Age

As many things that people consider iconically French (Eiffel tower, "Haussmann-style" architecture...)

</comment></comment><comment><USER9> This article reads like the quotes in [https://www.wired.com/1995/02/chess/](https://www.wired.com/1995/02/chess/) about how computers would never beat people at chess. Winning at chess required "fantasy" and "creativity" and here baking requires "passion" and "magic".

[https://www.cnet.com/news/bread-making-robot-makes- everyone-...](https://www.cnet.com/news/bread-making-robot-makes-everyone-at- ces-2019-trash-their-no-carb-new-year-resolution/) is a fully-automated bakery, although it doesn't produce baguettes, and [https://www.youtube.com/watch?v=5zfb456YrsM](https://www.youtube.com/watch?v=5zfb456YrsM) is half-automated from dough to finish; maybe we'll get a IBM Watson-style "robot bread" entry in the competition sometime.

<comment><USER10> The quotes in the Wired article are all kind of the opposite though. For example:

"Today, 99.9 percent of humanity cannot beat the best commercial software at blitz chess. Within the decade, it's likely the machine on your desk will know how to play chess better than any human has played the game since its invention in AD 600."

I suppose that really just makes your point though. Even in 1995 we were only really trying to delay the inevitable. If playing chess is ultimately a mechanical process and baking bread is ultimately a mechanical process, then ultimately we should be make able to make a machine that does it better than we can.

<comment><USER11> > Even in 1995 we were only really trying to delay the inevitable.

Do people do this? Are there really people out there that are resistant to believing that machines can or eventually will outperform humans in _any_ discrete task? I can see a reasonable doubt about general intelligence, but other than that surely every mechanical advance since the plow paints a clear trajectory.

These kinds of articles always strike me as absurdist handwringing. I suspect that it's just fear mongering for views. Is anyone here[0] actually in doubt about machines performing better than humans? I mean despite all of recorded history.

[0]I mean you, the reader yourself. Not speculation of other people's doubt, because I'm not sure these people exist.

<comment><USER12> Fair assertion. One I mostly agree with too.

But, what's the point then? I mean, if there's no point in pursuing anything because a machine will always be better and no one is going to appreciate anything handmade anymore... What's the point? To... eat, sleep and die?

I personally don't understand why a good portion of the population nowadays is okay with the idea that humans will be obsolete.

<comment><USER13> The point is simple: to paraphrase Marie Kondo, does it spark joy?

There are many things a human is better at, for example creativity and art. Maybe a computer will eventually be a better painter, but it's impossible for a computer to be a human. A work of art draws its power from how it speaks to the human experience, as such I don't think a computer will ever make good art in that sense.

Even speaking to something more concrete, just because a computer can play chess better than I can (as can the vast majority of humans), doesn't mean a game of chess with a friend is worthless. It's about the conversation, the challenge of matching wits, pushing your mind to see new things, all those things have meaning.

That's the point.

<comment><USER14> Musicians and artists have been co-creating with machines (including AI) for about 50 years. We play with the machines. Look at any artist working with AI and you will see that the human artist does a lot of process, experimentation, editing and presentation. I think it's a weird personification to declare that computers will do everything themselves.

</comment></comment></comment></comment></comment></comment><comment><USER15> When I was a kid, we'd go to the Amish stands at the farmers market and get fresh made loaves of bread (just white bread), dinner rolls, cinnamon rolls, strawberry jam...it was dirt cheap and delicious, even if it wasn't a baguette (which I love).

Now that farmers markets are 'in', you can go there and get the same stuff. But it's so marked up it's not funny. 12 dinner rolls for $5.50? $8.00 for a jar of jam? A loaf of bread for $4.00!

My grandmother is long gone but I guess I could get some mason jars and research on the internet, make my own jam and can it. I can already make bread, but only bother to do it a few times a year.

I'm sure in another generation or so it will be a black art. Very few people do that sort of thing anymore, but if you went back 60 years, everyone did it.

<comment><USER16> How long does it take you to make 12 dinner rolls? \- More than 15 min of work? Then 5.50 sounds OK to me. \- More than 30 min of work? Now 5.50 are a bargain!

<comment><USER17> Why do you think making a dinner roll should be billed at the same rate of your job?

<comment><USER18> The comment you replied to didn't mention a specific rate, but in general, linking price to cost of production (including human time) makes a lot of sense. I don't understand why the two comments before yours are getting downvoted.

<comment><USER19> It seems like nonsense because "How long would it take for you to acquire a dozen eggs? First, you have to buy chickens, wait for the eggs to hatch etc. Therefore, you should be okay with paying an amount at the rate you're getting paid for that amount of time."

Yeah, let's just throw basic economics principles out the window, shall we.

</comment></comment></comment></comment></comment><comment><USER20> Some Japanese are also really good at the craft: [https://www.google.fr/amp/s/www.lexpress.fr/styles/saveurs/l...](https://www.google.fr/amp/s/www.lexpress.fr/styles/saveurs/la- meilleure-baguette-2017-est-preparee-par-une-japonaise_1909370.amp.html)

<comment><USER21> The Japanese always manage to excel at importing delicacies and perfecting them. Take for example Japanese whiskey, which is renowned and considered by some to be superior to the Scottish variety.

<comment><USER20> Well, in the case of bread, no. It's hard to find even decent bread here. But a lot of them are indeed learning very well to make good bread and pastry making in France. A least one baker in my region is taking advantage of this focused and hardworking workforce.

<comment><USER18> Japanese pastry is amazing. The best Baumkuchen, a special cake from germany that looks like the rings of a tree (baum = tree) and is considered a delicacy, now comes from Japan.

</comment></comment></comment></comment><comment><USER22> I like baguettes but not the crusty ones that shred your mouth root, or the ones with Palm oil

</comment><comment><USER23> And here I was hoping for a good repeatable solid recipe

<comment><USER24> I put a lot of time into perfecting my baguettes. Well, not perfecting, but getting them to the point where they don't make me anxious.

I don't think reliably good baguette is as simple as a recipe. The recipe conveys very little of what goes into it. It takes a lot of practice to get down all the manual techniques. Just learning how to knead the bread properly is an art in and of itself, and, even if you use a mixer, you'll still need to experiment with the speed and mix time to get things dialed in. A lame can be a tricky thing to work with, and your slashing technique will show through in the final product. Pre-shaping and shaping the bread takes practice, and, unless you're really into climate control at your house, learning how to adjust ingredient quantities and rise times to account for changes in temperature and humidity is a science in and of itself. You'll have to fiddle with the bake time and temperature and steaming technique to figure out what works best in your oven.

Baguette is the pale lager of breads: Most the flavor comes from the technique, and the ingredients - four simple ingredients, very nearly the same four simple ingredients - have such delicate flavors on their own that there's not really anywhere for even the slightest mistake to hide.

Which isn't to say that you shouldn't do it. But I would say that you should do it because you sincerely love the process of baking bread, not simply because you enjoy eating the final product.

FWIW, one of my favorite books on the subject is _Bread: A Baker 's Book of Techniques and Recipes_ by Jeffrey Hamelman. The recipes are mostly meant for baking on a commercial scale, but the book also covers everything you need to know to adapt them to your home kitchen.

<comment><USER25> Quite agreed. My family bakes all of our own bread. In fact, the kids don't even like store-bought bread unless it comes from some fancy bakery. One of them has gotten into baking.

In addition to what you say, my advice is: Don't be afraid of it, just give it a try with realistic expectations. Start with something easy. Rolls and breadsticks are quite forgiving, if for no other reason than that they're usually gone before anybody can complain. ;-) Virtually any "failure" of bread can be redeemed by making toast, french toast, croutons, dipping in olive oil, etc. White is easier than grains, but you can work more grains in as you gain confidence.

Nice shapely loaves that I can make into sandwiches are the pinnacle for me, because I love my sandwiches.

When considering recipes, look at the timing of the steps. A recipe that fits with your schedule is more likely to be successful in the long run.

<comment><USER24> Speaking of schedule, _Artisan Bread in Five Minutes a Day_ is one that worked well for us when we were busy. It's not the _best_ bread in the world, but, considering the amount of effort that goes into it, the technique feels like cheating.

<comment><USER25> I should mention one more point, which is that a fair amount of the time spent making bread, is waiting. If you can interleave it with other tasks happening at home, then it isn't a huge time sink.

</comment></comment></comment></comment></comment><comment><USER26> This article is not really about bread though, is it?

</comment><comment><USER27> Is not really factory produce-able like original ciabatta- cause one part of the recipe that makes the taste, cant be effectively integrated. Its time. You need little yeast, you put the poolish in a olive-oil covered cup, and put it somewhere cool. And there it stays - for nearly a day. Then you add flour- and let it slowly come all the way. Then for all your work you get little bread. But it tastes oh so good. French bakerys - have a very limited supply of baguetts - because they have limited space to let the dough ripen for a hour or more (if it ripens cold). [https://bakerbettie.com/french-baguette- recipe/](https://bakerbettie.com/french-baguette-recipe/)

Not interesting on a industrial scale.. which is why you usually get only the tasteless whitebread you usually get.

<comment><USER28> We manage to factory produce prosciutto, which takes 18 months, cheeses that require years to mature, alcohol that takes decades, etc. 24 hours is no obstacle to a factory.

<comment><USER29> Mass producing baguette is done in many supermarket in France, but I've never tasted any good one coming out of it

Producing a good baguette is an art, meaning that a good boulanger knows how to take into account many external factors like humidity in the air to adapt the recipe (% of water, prep time, cooking time). produce consistent result and a baguette that taste good and fresh for a full day.

As for the number of baguettes produced in one batch, it is also because baguettes (different from other bread that last serveral days) are really better fresh. Fresh from the oven (for breakfast !) is best, half a day is good, 1.5 day and still good means you have a very good boulanger.

<comment><USER28> Supermarkets are going to target "cheap and good _enough_ ", in general. An industrial-scale factory can control for a lot of those external factors - it's a lot more likely to have humidity and temperature control, automation that ensures precise timings and measurements, etc.

I do agree that freshness is key with breads like this - there's nothing like a freshly baked one, and I still miss the morning croissant and baguette from when I stayed in Paris years ago.

<comment><USER29> You want to adapt the recipe for the weather outside of the bakery / factory not only for what happens in the bakery, i.e. cook it a bit more when it's supposed to rain so the baguette doesn't become soft / stays crunchy. That can be done at small scale, but is difficult at industrial levels.

</comment></comment></comment></comment></comment><comment><USER30> The poor man's brioche...</comment>


Ask HN: How to set up a tech stack/engineering practices for a new team? - <AUTHOR> I'm currently talking with a non-software tech startup that is currently hiring several developers to create a new product. And it sounds like they don't really have explicit engineering practices or a tech stack. So if I ended up there I would be taking a lead role in defining practices and the tech stack. So I was wanting suggestions for several things.
What works well for git? I'm currently looking at gitlab and github but I haven't really spent much time researching the differences. I don't want to self-host the repo.
What project management apps would be useful? I'm wanting bug tracking, code reviews, and some kind of project management software. I used Visual Studio Team Services a couple years ago, and liked it, but I'm not attached to any one product.
Should I use continuous integretion, and what level of automated testing should I have? I've heard some complaints about running unit tests before any commit?
And should testing and code reviews be required for all commits? It's a small startup so there might be some pushback. I don't think they currently do any of that.
The dev team will probably be between 5 and 10 users right now. They are developing a windows desktop application and use AWS. So a setup that works with windows and linux would be good.
Does anyone have any other general suggestions? <comment><USER2> Why don't you let the actual engineers decide on the engineering questions, ffs? If you were making aircraft parts, would you ask the internet what software you are going to decide for them to use? No you wouldn't even be allowed to decide unless you were a veteran engineer with some licenses. "I wanna make some wings. We are bringing on 10 aero engineers. what kind of tools and metals should I set up? I heard swept wing is good to use, what are your thoughts. I am leaning towards slide rules, but I heard RPN calculators work well."

<comment><AUTHOR> It's a small startup that hasn't been around for years. And it isn't a purely software focused company. Most of the engineers will be joining soon to start on this new product. They don't have a ton of engineers currently at the company.

<comment><USER2> Then hire some engineers and let them decide. If they don't immediately know what they want to use then you are not hiring engineers, you are hiring wannabe's or college kids.

</comment></comment></comment><comment><USER3> As far as testing goes, there's no one correct answer. It depends on what your goals are (and they'll probably change over time). E.g. if you're rewriting all the code every other week unit tests won't help you much. And unit tests won't catch many bugs. On the other hand unit tests can be extremely useful if much of your code needs to be stable and consistent.

My current second-best explanation of how to choose testing based on goals is written up here: [https://codewithoutrules.com/2017/03/26/why-how-test- softwar...](https://codewithoutrules.com/2017/03/26/why-how-test-software/)

(My best explanation is currently a slide deck that will become the third version of that post.)

</comment><comment><USER4> Unless you're starting with zero.. Skills on the team? Current stack?

If nothing then I do this:

Git and stash. An agile approach, features and user stories. An agile board. Vsts or rallydev Yes to continuous integration, deployment and automation. Testing, unit tests first. A desktop application may have specific technologies so .. depends.

Oh and code review, pull requests and I actually advise desk checks before submitting PRs.

Regular demos of sprint work is essential

<comment><AUTHOR> Those are good points. Tech stack can be anything as long as it runs on windows.

What's the benefits of doing desk checks and code reviews?

<comment><USER5> Code reviews are one of the best ways we've found to improve code quality. If you're not familiar with it, then you should read up on it. There are plenty of resources out there discussing code reviews (e.g. [http://dl.acm.org/citation.cfm?id=2597076](http://dl.acm.org/citation.cfm?id=2597076) or Steve McConnell's "Code Complete".)

Think about it this way. Code is as complicated writing. There is no successful media organization in the world that would publish a book or magazine without at least having one round of review, because hundreds of years of practice has shown that review improves the final product significantly. It's hubris to imagine that programmers are any better than authors.

<comment><AUTHOR> Oh, definitely. Code reviews are really valuable. I'm just curious about desk checks in addition to code reviews.

Edit: that paper's pretty interesting. I haven't really thought about what made good code reviews and what the causes of defects are.

</comment></comment></comment></comment><comment><USER6> The #1 guiding principle for answering these questions that I've found is: Start with "Why?".

Why are you writing any code at all?

Are you writing code to test a hypothesis and present the results of testing that hypothesis to other people? If so, state that hypothesis explicitly, build the minimum needed to test that hypothesis, and have a clear & concise document (Dropbox Paper, README.md, etc) explaining how the code tests the hypothesis.

Are you writing code to build a product that you plan to maintain for 5-10 years as you add features and support a larger user base? That implies that in 5 years, you are going to have some new junior engineer join the team who will need to figure out how to navigate this codebase and modify it. They will have a job to do and the UI they have to accomplish this job will consist of:

\- The codebase itself (including any tests)

\- The commit history of the codebase

\- Any diagrams or READMEs that were written alongside the codebase

\- The issue tracker

\- The other members of the team and their memories and communication habits.

Engineering practices and team habits matter because they mean that your more junior engineers are able to much more quickly and confidently do projects to solve evolving business needs as much or writing as many bugs. Think of both your codebase and your project management tools as a UI whose users are the engineering team trying to accomplish business needs. This talk is close to the mindset I'm trying to convey: [https://skillsmatter.com/skillscasts/10124-dylan-beattie- the...](https://skillsmatter.com/skillscasts/10124-dylan-beattie-the-pursuit- of-apiness-the-secret-to-happy-code)

Speaking personally, I find that automated testing is extremely useful for moving quickly because it makes it easier for me to break a task down into concrete pieces and to stay motivated by having constant positive feedback. The cost of testing is that it takes a while to set up and is especially difficult if you are not experienced in the toolset you are using. If you don't have a good testing toolchain in place, then writing and running tests is really painful and gets in the way of development

For this reason, it is tremendously useful to have testing infrastructure and practices set up early on in a project by someone who is experienced with the particular framework/language you are using. It is very difficult to introduce tests after-the-fact.

The branching and code review process that I've found most useful is:

```

$ git checkout -b my-feature

# Write some code.

$ git add -p

$ git commit -m "do some small thing"

$ git status

$ git checkout file/that/has/leftover/edits/I/dont/want

# Repeat.

$ git rebase -i HEAD^^^^^

# re-order commits, edit commit messages, and squash some commits into

# larger logical blocks.

$ git checkout master

$ git pull origin master

$ git checkout my-feature

$ git rebase master

# It now looks like my-feature was developed off the tip of master

# And I've resolved any potential merge conficts.

$ git push origin my-feature -f

``` And then make a pull request to merge to master and tag someone to review. CircleCI runs the full automated test suite on the PR. I've only run the few tests that I've modified because they're the ones that relate to my PR. It doesn't make sense to require passing tests for every commit because then you can't write PRs where the tests fail. You might want to do this so you can show someone a Work In Progress and ask for advice. It might make sense to run a linter like rubocop on each commit, but only if each of the linter rules is agreed-on by the team (just make a PR for it and have people +1 or -1).

If I need to make changes to the PR after pushing, I do so and then I rebase on top of master again and `git push -f` the branch. Once tests pass and someone +1s it, I'll merge to master and start on the next chunk of work in the project. Note that on Github, if you tag someone for a review, and they make a comment, you need to tag them again for your PR to show up in their list of PRs-to-review.

Keep your work tightly in-sync with master. If there is a feature that I don't want to go live, I use a feature flag to turn it off rather than keeping it out-of-sync with master. Merging large changes that have gotten far out of sync is hell.

For project management, try to be as lightweight as you can. We use a 1-page markdown doc of "Here are good questions to ask to make sure you've understood the scope of the problem and have talked to relevant stakeholders." and we break the project up into trello cards that roughly correspond to PRs.</comment>


Undrln (new social news site for "advertising, marketing, and design") - <AUTHOR> http://www.undrln.com/

<comment><USER2> Just subscribed. Looks like there's some cool stuff coming through. But what really bugs me is that the links in the feed go to undrln.com and not directly to the site that the link's for. Making me click twice is not good. And we all know why they're doing it. Not for the subscriber, that's for sure.

<comment><USER3> Agreed--that pisses me off too. That being said, this is only a problem with RSS readers. The site itself links directly to the post.

We are going to fix the RSS component, but chose to hold off on that until we saw how the uptake was. So far it looks promising. Nearly 7,000 uniques on the first day.

As for the clicking twice, there's no ulterior motive there. It's just a limitation of Drigg that we're going to have to hack around.

<comment><USER2> Hm yeah. I hear you. Now I feel bad about suggesting an ulterior motive with the rss links - it's just it really strikes a nerve when I see that. Good luck hacking around - and good luck with the site.

<comment><USER3> Don't worry about it--I can see how one might think that we were just trying to increase clicks. That being said, once we have a moment, we'll certainly be fixing this.

Besides, I expect to be the site's most active user. The last thing I want is to be hampered by extra clicks. :-)

</comment></comment></comment></comment><comment><USER4> The hardest part about building a successful social news is building the community, good luck. Getting marketing and advertising people to remember u-n-d-r-l-n dot com is going to be an effort in itself.

<comment><USER5> Undrin sounds like a pharmaceutical product. Undrin helps you regain control of your bladder. Side effects include dizziness, headache, nausea.

<comment><USER6> Do not taunt Undrln.

<comment><USER3> Indeed. The undrln doesn't like that. ;-)

</comment></comment></comment></comment><comment><USER7> I just think they are too many social something sites out there at this time. The trend should slow down a bit to allow users to awake from the ongoing drunk fest of social tools.

<comment><USER3> To be honest, I don't think it's really a social site. It's far too basic for that. Mostly, it's a place for me (specifically me) to start the day. I love the HN format and visit it every day. That being said, I wanted more content related to design/marketing, given that it's what I do a lot of.

I felt that if I wanted something like this, my peers might also. (So far that theory seems to be holding, but who knows if it will be compelling in a week's time.)

</comment></comment><comment><USER8> Subscribed, looks promising.

Don't like the banner, too much screen real-estate lost, also the give-your- email-and-we'll-send-you-a-password-thing is getting kinda old.

<comment><USER3> I suppose. The top area is intended to afford fly-out ads at some point. I'm sure that makes you shudder, but I'd be pretty happy if we could eek a couple of bucks out of it. (Heaven knows we're good at making neat things that don't generate any cash.)

As for the email/password thing, we're just trying to manage the spam component. Communities like this can easily get run-over, without introducing a few little obstacles.

</comment></comment><comment><USER9> Un.. durr.. lin?</comment>


Introducing Xubuntu core - <AUTHOR> http://xubuntu.org/news/introducing-xubuntu-core/

<comment><USER2> This looks great. I've continually chose Xubuntu because it's Ubuntu without a lot of the fluff. I've wondered if there was an easy way to remove or not install the few other things that I don't use (like Abiword and Parole). Will be trying this later today.</comment>


Scientists Send Text Message Using Vodka - <AUTHOR> http://www.voanews.com/content/scientists-send-text-message-using-vodka/1813783.html

<comment><USER2> A rather linkbaity headline; I send text messages using vodka pretty often, and then I have to check to see what exactly I said in the morning.

Interesting, though. Seems like a series of breezes could seriously impact the communication, though, making the whole robots-in-the-sewer system not work quite so well.

<comment><USER3> MITM issues are far more uhh... interesting ... as well.

<comment><USER4> "Bob sends Alice his scent. Mallory intercepts the smell, pretending to be Alice to Bob and Bob to Alice."

Ahem.

</comment></comment></comment><comment><USER5> Other submissions of this story, although none have any discussion:

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

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

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

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

[https://news.ycombinator.com/item?id=6939145](https://news.ycombinator.com/item?id=6939145) (plosone.org)

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

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

<comment><USER6> The actual study, which you have buried in that list of links, is actually quite nice.

[http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjourna...](http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0082935)

They achieved about .3 bits per second.

Components needed to replicate:

* DuroBlast Electronic Spray

* Arduino: [https://www.sparkfun.com/products/11021](https://www.sparkfun.com/products/11021)

Alcohol Sensors:

* MQ-303a : [http://www.seeedstudio.com/depot/alcohol-sensor-mq303a-p-549...](http://www.seeedstudio.com/depot/alcohol-sensor-mq303a-p-549.html)

* MQ-3 : [https://www.sparkfun.com/products/8880](https://www.sparkfun.com/products/8880)

* MR513 : [http://www.cooking-hacks.com/mr513-alcohol-high-accuracy](http://www.cooking-hacks.com/mr513-alcohol-high-accuracy)

So their setup is probably about $100

</comment></comment><comment><USER7> I would be more interested if they sent vodka using text message

</comment><comment><USER8> Text messages are only the relatively boring first step in this kind of project. If these guys go on to implement IP/Vodka they can proudly follow in the footsteps of such hacks as RFC 1149 :-) "The network smells a little slow today"

</comment><comment><USER9> Pretty neat that I know the people in this article personally.

</comment><comment><USER10> So what's the baud rate?

I might guess something like one bit, every 10 seconds?

<comment><USER11> Given huge number of possible molecules and the relatively slow nature of wafting them around the room, I suspect they plan to pack a lot more that 1 bit of information in each molecule!

</comment></comment><comment><USER12> Sounds like they're shooting for an Ig Nobel prize.

[http://en.wikipedia.org/wiki/List_of_Ig_Nobel_Prize_winners](http://en.wikipedia.org/wiki/List_of_Ig_Nobel_Prize_winners)

</comment><comment><USER13> I think it's worth exploring non-standard means of establishing networks no matter how ostensibly silly as they can come in extremely useful when e.g. governments try to restrict internet access in oppressive countries or natural disasters occur, etc.

Though I'm not sure if this particular example is of much use ;-)

</comment><comment><USER14> I think the Native Americans did the same thing with smoke. "Smoke" for 1, "no smoke" for zero. And they went way further than across the room.

<comment><USER15> Sort of, but they didn't smell the smoke signal, just look at it. It's cool that we can automate it too.

<comment><USER14> Point a camera at the place where the smoke pit would be. Poof! Automation.

As to smell, that was a stupid way to do it.

We can detect levels of lots of different things. Instead of 1 or 0 over time it would have made a lot more sense to say Ok, I need to be able to encode 140 characters with 37 choices (alpha-numeric + Space).

There is a humidity sensor, a Carbon monoxide sensor, an oxygen sensor, and a Carbon dioxide sensor. All are really cheap.

If you a tube and 37 levels that you release water, carbon monoxide, oxygen, and carbon dioxide to. You now have the ability to send. 4 characters at a time. Since alcohol sensors are cheap, we can use that for "parity" so we know that the message was sent correctly.</comment></comment></comment>


414M pieces of plastic found on remote Australian islands: Study - <AUTHOR> https://edition.cnn.com/2019/05/16/asia/australia-plastic-islands-intl/index.html <comment><USER2> I think MIT designed a bacteria that eats plastic, wonder what's taking them so long from deploying it.</comment>


A minimal list of common well-known algorithms, classified by purpose - <AUTHOR> http://www.scriptol.org/list-of-algorithms.html <comment><USER2> " The goal is to provide a ready to run program for each one, or a description of the algorithm" - a noble aim - worth contributing to a resource like that.

</comment><comment><USER3> Should team up with <http://en.literateprograms.org/>

<comment><USER4> Literateprograms.org strikes me as a much better-implemented site; as a wiki, it doesn't rely on being populated by an individual, and all the pages are locally hosted. It doesn't limit itself to a small set of programming languages, either. It could use a list like this, though.

<comment><USER5> Agreed - I only have minor gripes with the list, but given that only a handful of the algos have implementations, this thing would really need to be a wiki for it to have any hope of getting completed. Frankly, I'm not going to bother sending an email with new implementations and wait to see if it's approved, whereas I might have dropped by now and again to help populate a wiki.

</comment></comment></comment><comment><USER6> While the list is noble, I have difficulty trusting the source. Other pages on the scriptol.org website are somewhat immature and, unsurprisingly, full of Scriptol propaganda.

</comment><comment><USER7> This is fairly comprehensive:

<http://www.nist.gov/dads/>

<comment><USER8> aw.

<http://www.nist.gov/dads/HTML/marlena.html>

<comment><USER4> Hah.

And the very next entry in the index is "marriage problem". :)

</comment></comment></comment><comment><USER9> One algorithm (alpha-beta) under the whole section of Artificial Intelligence, and six different primality tests? That seems a little extreme.

<comment><USER4> Hmm... It appears Wikipedia has stolen his list and filled in all the links, over the course of the last eight years:

<http://en.wikipedia.org/wiki/List_of_algorithms></comment></comment>


The Streaming Stick Built on Firefox OS - <AUTHOR> http://www.matchstick.tv/

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

</comment><comment><USER3> This looks awesome! I bought an Amazon Fire TV Stick when they were accepting pre-orders at $19, and while it works well for that price (or even the $39 current retail price), I would much rather it be hacker-friendly. It doesn't even have a web browser! I could see using it for all sorts of additional projects, if it were more flexible...and given how much horsepower they've crammed into it (it's comparable to a decent laptop from a decade, or so, ago, and can even do 1080p video, which even modern laptops can't always do reliably), I could imagine using it for all kinds of cool stuff.

Stuff like a project dashboard that users could update from their phone or laptop, a party music playlist determined by partygoers, so many cool things a tiny little device like this could make easier (it's not the only way it can be done, but it's certainly nice having a tiny little dedicated device, and would be better for being open).

In short, this looks really cool, and I'm actually really eager to start developing for Firefox OS, even though I currently don't have any Firefox OS devices.

Edit: Reading the other HN thread about this device raises a lot of concerns about their dedication to Open Source and Open hardware. It seems to simply be a marketing lie, which is troubling, and makes me far less interested in the device (maybe not interested, at all, since I already have a proprietary HDMI dongle in the form of the Fire Stick).

<comment><USER4> I got a FireTV stick as well, and I am having a lot of fun hacking it.

You can sideload most Android apps including Chrome, Firefox and XBMC/Kodi without rooting.

You can also install an AirPlay app and use it as an AirPlay receiver.

<comment><USER3> Cool. I didn't know that it could side load apps. That kinda changes everything. I didn't notice settings for that. I also got a Fire Phone during the Christmas sale, and once I got Google Play Store on it, it became a _much_ better phone...almost good.

</comment></comment></comment><comment><USER5> In the video there is no usb cable to power the device like the chromecast or roku stick. I suppose it needs one too ? It's a shame that advertisement for these devices "lie" about it.

<comment><USER6> The Chromecast does not require external power; it'll run off the power supplied via the HDMI port. I'm pretty sure the Amazon FireTV Stick will, too. I don't own a Roku Stick, so I can't comment.

They _prefer_ having external power because many HDMI ports don't supply enough consistently, but don't require it.

<comment><USER7> HDMI provides about 50mA minimum. USB can provide up to 500mA or 900mA depending on USB 2 or 3.

I am not 100% sure what the power requirements for a Chromecast are, I'm 100% sure it is more then 50mA.

If you are plugging in your Chromecast to your TV without the USB and it is working it's because you have a MHL-HDMI that provides up to 900mA of power.

</comment></comment></comment><comment><USER8> Update #10 [1] will please travelers: AdHoc mode allows you to use it even when you ordinarily can't get a TV stick to authenticate through the lame-o hotel wifi.

[1] [https://www.kickstarter.com/projects/matchstick/matchstick-t...](https://www.kickstarter.com/projects/matchstick/matchstick- the-streaming-stick-built-on-firefox-os/posts/1040108)

<comment><USER9> You can get around some of the captive portals by MAC-spoofing the stick of your choice through your laptop to authenticate (then switching back). It's a pain in the arse, but it works in a pinch.

Ad-hoc will make most of that pain go away.

</comment></comment><comment><USER10> I got my dad a chromecast. He's tech-illiterate, for the most part--can check his email, type in searches, but he doesn't really know where he's typing his searches. He might want a youtube video but type it into google, the url bar, youtube's search...which all work, but he's not seeing the difference.

Anyway, he loves it. He used to watch pool videos incessantly in a really bad computer chair, now he can watch them on the couch. Probably average of 3 hours per day. He had some trouble with the interface, and he kept pointing his iphone at the TV like it was a remote, when I showed him how to control it via the phone.

Anyway, any chance this is simpler from that perspective? Or should he just suck it up with the CC? (I think he's been doing fine now, honestly)

<comment><USER11> Probably just the CC, based on your use cases listed.

The use of Open Flint is interesting here, since it isn't tied to any major digital retailer. Amazon prime video won't work over Chromecast because, well, Amazon Prime competes with Google Play.

It's too bad that Flint is coming to the game this late - it would have been great if they had been there at the beginning of the market and became more of a standard.

</comment></comment><comment><USER12> Waiting for them to ship mine. I'm looking forward to having something I can actually put my own code on.

</comment><comment><USER13> Does any one know when this is coming out?

<comment><USER2> Developer units have shipped. I haven't seen a date for a consumer release.

[https://www.kickstarter.com/projects/matchstick/matchstick-t...](https://www.kickstarter.com/projects/matchstick/matchstick- the-streaming-stick-built-on-firefox-os/posts/1069012)</comment></comment>


Weex – A framework for building Mobile cross-platform UI - <AUTHOR> https://github.com/alibaba/weex <comment><USER2> most helpful technical page: [http://alibaba.github.io/weex/doc/advanced/how- it-works.html](http://alibaba.github.io/weex/doc/advanced/how-it-works.html)

has vdom and renders to native or html5, aims for 100% code reuse</comment>


Coursera Calculus course with hand-drawn animated materials - <AUTHOR> http://boingboing.net/2012/12/04/free-coursera-calculus-course.html

<comment><AUTHOR> Detailed syllabus: [https://s3.amazonaws.com/coursera/topics/calcsing/SYLLABUS_S...](https://s3.amazonaws.com/coursera/topics/calcsing/SYLLABUS_SVC.pdf)</comment>


Normalized data is for sissies  - <AUTHOR> http://www.kottke.org/04/10/normalized-data <comment><USER2> I was about to say that denormalization is so 2004, and then I noticed that he made that post in 2004.

</comment><comment><USER3> Well, the smart thing would be to store the data in normalized tables like your supposed to, and then denormalize it with a fast refreshed materialized view (or one that is updated on a schedule, depending on how stale data can be tolerated), or add the extra speed with a caching layer.

If your hitting flickr traffic, then you have some tough problems to solve, but I don't think starting your app with non-normalized data would be very smart!

</comment><comment><USER4> "the scalability problems being described in your post, and in his presentation, could easily be rectified through the use of indexes and stored procedures."

Not all scalability problems can be solved by throwing indexes and stored procedures around. A improperly designed schema just for the sake of normalizing everything can cost a lot in terms of performance. On the other hand keeping 13 copies of the same data around sounds scary.

</comment><comment><USER5> It sure does this: "Makes searching faster" As long as you take care of this little nit: "Have to ensure consistency in the application logic"

</comment><comment><USER6> It took me quite a while to realize he was talking about normalized _databases_. "Normalized data" generally means something else.

</comment><comment><USER7> I remember working for a small company with a moderately successful web app for the real estate industry. I had to make a modification to one of the data models so I downloaded a trial of an expensive ER app to reverse engineer the SQL server DB. The tool revealed zero foreign keys - I thought it was an error until I confronted the on-his-way-out developer who had written the app. He said he got tired of having to change the data model constantly - that he decide to wipe out all the FK constraints. In his mind, the constraints were in the code.

</comment><comment><USER8> What is the ratio of retrieving (reporting) to updating? You just may want to ask this question before you decide how far to normalize your data. Got 13 instances of the same thing? EVERY ONE of them must be updated simultaneously with EVERY update (including all the necessary locking, committing, etc.)

Calling people sissies is what sissies do. (Oops, does that make me a sissie?)

<comment><USER9> I agree. I think the best strategy is to start with a normalized database, and only denormalize when you measure a problem that can't be fixed by adding an index.

<comment><USER10> I'm working on a project where we're in the process of storing de-normalized links for a recursive table relationship, so we can query from the top-level table directly to the bottom-level table without worrying about the messy inbetween. One of the few non-speed reasons I've ever come across where denormzalization seems jutified.

<comment><USER9> Might want to check Joe Celko's Trees and Hierarchies in SQL to see if there's a normalized way to do what you want.

<comment><USER10> Thanks. I just overnighted it from Amazon. My coding partner wants to use recursive database queries to do this--I want to avoid it because it's slower, breaks our object model, and makes the application non-database-agnostic. (Currently, we're using NHibernate and can run on most major databases.)

</comment></comment></comment></comment></comment><comment><USER11> SQL databases are such marvels of engineering and computer science!

(cough, like hell they are...)

<comment><USER12> What's wrong with them?

<comment><USER11> Where to start..

For one, while we're on this denormalization topic, postgresql refuses to use indexes sanely when I run queries against views. Heck, I don't see why postgresql even has views if they can't really be used.

Yes, I am complaining about the performance of current implementations of relational databases, not how good they "theoretically" could be. Still, after this many years, it's apparent that they aren't going to be getting better any time soon!

<comment><USER13> You need to implement materialized views using triggers. Not ideal but sometimes it has to be done.</comment></comment></comment></comment>


CES 2009: Palm Press Conference - <AUTHOR> http://www.crunchgear.com/2009/01/08/ces-2009-palm-press-conference/ <comment><USER2> "Don't call it a comeback, I've been here for years..."

After all the ups & downs of PalmSource, Palm OS 6, etc., since what, 2004?

I don't know if they'll win (but the old palmos-lover in me hopes for them, even though I'm on an iPhone now...), but three good competitors promises a very good fight in the mobile smartphone arena.

If they mention that the OS has a bit of BeOS in there, I'm going to tear up.</comment>


Interoceptive Ability Predicts Survival on a London Trading Floor - <AUTHOR> http://www.nature.com/articles/srep32986 <comment><USER2> >We monitored these traders during a particularly volatile period (the tail end of the European sovereign debt crisis) so the performance of each trader reflected his ability to make money during periods of extreme uncertainty.

Shouldn't the market state be a pretty big experimental control?

If we're coming out of a downturn and the market is going up, on average anybody taking a financial risk would be rewarded for doing so.

It would be interesting to see the same group in a financial situation in which the market is at a peak and headed down. Are these traders who have greater interoceptive ability able to take the _right_ risks since, on average, those who take on risk before a downturn lose money?

<comment><USER3> These guys were trading futures contracts. Unlike stocks, when you are long a futures contract, someone else is necessarily short, so it won't be the case that "anyone taking financial risk would be rewarded".

<comment><USER4> Not necessarily - for stock index futures, the seller of the contract can simultaneously buy the index of stocks. When the future contract reaches maturity the seller has to "deliver" the basket of stocks to the buyer. Banks and market makers make money writing (selling) such index futures by buying a smaller basket of stocks than are strictly in the index to get the same hedge effect (using principle component analysis, yay!), consolidating an entire portfolio of contracts and having a single hedge, and also by having lower transaction costs to buy/sell the underlying stocks than the clients buying/selling the future would, because they already have all the expensive exchange memberships, they also may have inventory, and they have dark pools, in which their own traders get first priority.

</comment></comment></comment><comment><USER5> Interesting paper, but I have issues with some of the statistics--not helped by the large number of seemingly exploratory analyses that give the impression of a garden of forking paths.

1) The authors go through the work of doing several simpler analyses which are obviated by the final multiple regression. The analyses (in Wilkinson notation) _P &L_[0] _~ HBD_ [1] and _HBD ~ covariates_ only provide a subset of the information in the final _P &L ~ HBD + covariates_. The paper would improve if the preliminary analyses were replaced by a more thorough treatment of the multiple regression.

2) From what I gather, the maximal model containing HBD and the covariates was fit and then variables were subtracted successively based on whether doing so reduced the AIC. This does not seem like the right choice at all, and could possibly have influenced the final result. Selecting an optimal model is _not_ the goal here, yet that is what this process is designed to do. The research question is about the influence of HBD on P&L, not predicting P&L from some optimal combination of variables. So, the theoretically important covariates should have remained when testing the significance of P&L. The point of the covariates is to "control" for confounding factors or "stress test" the importance of HBD in the presence of confounds, not to increase the predictive power of the model.

3) Trader and session length are actually random variables but their error is not modeled. Instead, the results from all sessions are averaged for each trader. Taking the average has the result of undercounting the variance and misspecifying the variance structure. Something like a multilevel model with crossed random effects should have been used instead.

[0] "Average daily profit and loss" \- measure of trading performance.

[1] "Heartbeat detection score" \- how well the trader self-assesses their heartbeat.

<comment><USER6> Is 18 traders a large enough sample? To me (no expert), it seems like a really small sample size..

<comment><USER5> It's a fairly small sample. However, in theory it's still possible to detect an effect in a population using a small sample if the effect size is large enough. Unfortunately, the paper doesn't present a measure of effect size, e.g. standardized regression coefficients.

</comment></comment></comment><comment><USER7> There's a great anecdote about George Soros that this reminded me of: Despite the palindrome writing two dense books and conducting numerous interviews on his theory of 'Reflexivity'[0] as essential to his success, Soros' son thinks it really comes down to something like interoceptive ability, which Soros reasons is a combination of "theory and instinct"[1]:

.

.

 _According to his son, Robert, Soros's trading was always influenced by more than reflexivity. "My father will sit down and give you theories to explain why he does this or that", he once said, "but I remember seeing it as a kid and thinking, 'Jesus Christ, at least half of this is bullshit'.

"I mean, you know [that] the reason he changes his position on the market or whatever is because his back starts killing him. It has nothing to do with reason. He literally goes into a spasm and it's this early warning sign."

Soros has admitted to relying greatly on "animal instincts", saying the onset of acute pain was often "a signal that there was something wrong in my portfolio".

His decisions, then, "are really made using a combination of theory and instinct". _

[0]: [http://www.mercenarytrader.com/2014/02/lessons-from-the- pali...](http://www.mercenarytrader.com/2014/02/lessons-from-the-palindrome/)

[1]: [http://bclund.com/2014/08/20/nothing-can-learn-george- soros/](http://bclund.com/2014/08/20/nothing-can-learn-george-soros/)

</comment><comment><USER8> Oh awesome. That is a word I've been looking for.

It lead me to [http://www.nature.com/neuro/journal/v7/n2/full/nn0204-102.ht...](http://www.nature.com/neuro/journal/v7/n2/full/nn0204-102.html)

Which formalizes the directions I've started to think about, namely the connection and feedback loop between physical sensation and emotion.

<comment><USER9> You might like Craig's paper "Interoception and Emotion: A Neuroanitomical Perspective" [https://books.google.com.au/books?id=DFK1QwlrOUAC&pg=PA272&h...](https://books.google.com.au/books?id=DFK1QwlrOUAC&pg=PA272&hl=en#v=onepage&q&f=false)

He presents evidence that primate emotion evolved from interceptive awareness - goes into fascinating detail about what we know of the underlying, homeostatic, neuroanitomical structures and their evolution.

</comment></comment><comment><USER10> "Our results suggest that signals from the body ... contribute to success in the markets"

Does it suggest that physiological emotions help traders make good decisions? Or does it suggest that conscious awareness of physiological emotions helps traders compensate for gut biases and make more rational decisions?

<comment><USER11> The authors don't draw any conclusions either way ("Our study, being field work, could not establish causation"), but they seem to lean toward the former with this:

 _Traders in the financial world often speak of the importance of gut feelings for choosing profitable trades. By this they mean that subtle physiological changes in their bodies provide cues helping them rapidly select from a range of possible trades the one that just 'feels right'. Our findings suggest that the gut feelings informing this decision are more than the mythical entities of financial lore - they are real physiological signals, valuable ones at that._

The suggestion here is that there is a way in which the mind/body are able to rapidly process large amounts of information, beyond conscious analysis/calculation, and report an answer as a "gut feeling", and that the people who have a stronger ability to sense their physiological functions are the people for whom this mechanism is more accurate.

This notion seems analogous with the thinking behind practices like meditation and other mind+body "tuning in" exercises that have long been used in martial arts training to develop better spatial awareness and more precise reflexes.

</comment></comment><comment><USER12> Cyborg trading experiments, anyone?

What happens if you combine physiological signals with machine learning to create an application that trades based on a human's "gut" along with other input, and perhaps historical data?

You can imagine a man vs man-machine competition where a trader's regular profit/loss is compared in real-time with the "enhanced" p/l.

What could be done if you network several traders' physiological signals and mix with machine learning and automated trading?

Is anyone doing this kind of frankentrading? Could even imagine going for scale with an Apple Watch physio-trading app :0

</comment><comment><USER13> I think that I've been able to observe a similar situation in my experience. I've had the fortune of being at the point of various crises in my career (massive system failures, natural disasters, man-made disasters, etc) in both contributor and leadership roles.

When in those type of situations, I definitely have perceived a heightened awareness, where the feeling is like being in the "zone". Decisions are easier, communications more fluid. I tend to be a more instinctual person in general, but these types of situations are far more pronounced.

<comment><USER14> What's interesting is that it's highly situational for me. I'm known as a fixer for work related situations but I'm pretty risk adverse in my personal life.

<comment><USER13> Same here.

I'm an awful negotiator in my personal life for cars, etc. I leave money on the table all of the time. At work, a few guys dubbed my face over William Shatner from a Priceline "negotiator" commercial and played it for the christmas party after a particularly tough deal. :)

</comment></comment></comment><comment><USER15> Related reading [1] starting at "Looking into traders' hearts."

[1] [https://www.bloomberg.com/view/articles/2016-09-19/tough- tar...](https://www.bloomberg.com/view/articles/2016-09-19/tough-targets-and- short-term-projects)

</comment><comment><USER16> My issue is that they didn't control for blood pressure. I know that I could tell my heart rate a lot easier before I regulated it down.

</comment><comment><USER17> Seems to me like one could just as easily conclude that people who are generally more perceptive/aware would do better on the trading floor.

</comment><comment><USER18> Am I more impressed that they managed to get traders to cooperate? Did some distracted trader take a massive haircut for science?</comment>


Ask HN: How do you think Cambridge Analytica harvested Facebook data? - <AUTHOR> Reading the stories around Cambridge Analytica and the facebook "breach" I can't help to think that this was merely done by accessing the Facebook API.<p>A simple naive solution really. So why the hype ? Serious question. <comment><USER2> It wasn't a hack or using loopholes, "just" and app that collected more data than legal given current data privacy laws. So the term "breach" is more like a breach of contract. Facebook took two years to act which raises questions now serious Facebook takes data breaches.

[http://www.businessinsider.de/cambridge-analytica-a-guide- to...](http://www.businessinsider.de/cambridge-analytica-a-guide-to-the-trump- linked-data-firm-that-harvested-50-million-facebook- profiles-2018-3?op=1&r=US&IR=T)</comment>


Goldman Sachs is doing something that would have been unthinkable before 2008 - <AUTHOR> http://www.marketwatch.com/story/goldman-sachs-is-doing-something-that-would-have-been-unthinkable-before-2008-2016-04-25 <comment><USER2> In business, whenever I select vendors I consider their motives and not their promises: What will they be motivated to do for me? Am I a big enough account to matter to them?

In this case, the motives I can imagine are marketing (make their brand more familiar to people outside Wall St, give people some personal connection to them, and have a political claim to serving more than Wall St) or meeting some regulatory requirements (as described in the article). But who knows; maybe there is more money in small depositors than I think.</comment>


The Best Startup Pitch Decks - Gurjinder-Singh https://merithub.com/gurjinder/the-best-startup-pitch-decks

<comment><AUTHOR> Great Collection!! There is a pattern in every deck. Best sequence of slides is:Cover, Summary, Problem, Solution, Product, Business Model, Market Opportunity, Competition, Growth Strategy, Traction, Financials, Team , Funding</comment>


Online altruists making Reddit more accessible - <AUTHOR> https://www.wired.com/story/online-altruists-are-making-reddit-more-accessible/ <comment><USER2> In 2014, the CEO Yishan Wong and lead investor Sam Altman said they were promising equity to some users of Reddit

[https://www.theverge.com/2014/9/30/6874353/reddit-50-million...](https://www.theverge.com/2014/9/30/6874353/reddit-50-million- funding-give-users-10-percent-stock-equity)

Any update on this?

<comment><USER3> > Money can become worthless very quickly.

Smart enough to foresee it, not smart enough to avoid it.

</comment></comment><comment><USER4> What is going to happen when Reddit ipo's and the employees benefit financially from it, but the moderators who actually make reddit what it is get nothing?

<comment><USER5> The internet has had paid and free communities and forums forever. I can't think of a single one where voluntary non-employee moderators got paid. Tech support forums for ten billion dollar companies also sometimes have non- employee moderators who I'm pretty sure are not paid.

<comment><USER6> AOL used Community Leaders to moderate chats and forums. The CLs filed a complaint with the Department of Labor for violations of the Fair Labor Standards Act (FLSA) and eventually sued, winning a $15 million settlement.

It's a violation of the FLSA to use volunteers to do unpaid work at a for- profit company, even if the volunteers are OK with not getting paid. It's only going to take one mod to file a DoL complaint before Reddit scraps all the mods or centralizes the mod duties under actual employees.

[https://en.m.wikipedia.org/wiki/AOL_Community_Leader_Program](https://en.m.wikipedia.org/wiki/AOL_Community_Leader_Program)

[https://webapps.dol.gov/elaws/whd/flsa/docs/volunteers.asp](https://webapps.dol.gov/elaws/whd/flsa/docs/volunteers.asp)

</comment></comment></comment><comment><USER7> Afaik there are now bots that attempt to transcribe text from images, which is rather apt given the spread of image 'memes' and screenshots of text like the greentexts mentioned in the article.

</comment><comment><USER8> Are these captions appreciated? The bland text seems to not be as entertaining/aesthetic as the images, and captioners never "translate" the image into a witty _writeup_ like a good _text_ joke that captures the essence of the visual.

<comment><USER9> Close your eyes. Now listen to a discussion among a bunch of people about an image they are looking at.

Would you appreciate being given a description of the image first, or would you rather just hear them talk about something you have not seen?

<comment><USER10> This didn't answer the question.

For we know it only added your biases.

What do actual people this is relevant to say? What do the actual users of this think?

<comment><USER11> Every response adds in the person's personal biases.

<comment><USER10> Yes, but I said 'only' your biases.

Top post specifically ask what do the actual people who might want this think.

Closing your eyes and pretending you are blind as an answer....

Compared to what does /r/blind think?

[https://www.reddit.com/r/Blind/search?q=TranscribersOfReddit...](https://www.reddit.com/r/Blind/search?q=TranscribersOfReddit&restrict_sr=1&type=link)

</comment></comment></comment></comment></comment><comment><USER12> This is cool.

I co-own a Google group called Blind Dev Works. I had no idea this existed.

</comment><comment><USER10> I thought the earlier post on "Why the Gov.uk Design System team changed the input type for numbers" says a lot in this part-

1\. Accessibility 1.a) cannot be dictated or selected when using Dragon Naturally Speaking 1.b) appears as unlabeled in NVDA's element list

We need to stop designing around visually impaired people and hold the tools into account. Why us Gov.uk spending 10's of millions on this rather than fixing the tools?

This makes no sense

"In r/DnDGreentext, one user spends hours transcribing 82,000 characters of text from screenshots of a Dungeons and Dragons roleplay game."</comment>


Microsoft Releases Bing API - With No Usage Quotas - <AUTHOR> http://blog.programmableweb.com/2009/06/08/microsoft-releases-bing-api-with-no-usage-quotas/ <comment><USER2> What the big companies are realising is this: When you get lots of small developers using your API, you have tens of thousands of people who are actively marketing your product through your API.

You don't need to build up any large marketing force anymore, just let the developers do for you. For example, facebook connect drives people to facebook, etc. The web is becoming an OS, and the big companies are trying to achieve developer lock-in by offering a lot of convenience APIs and platforms.

He who gets the developers will get the users.

<comment><USER3> It was fun to laugh at at the time, but Steve Ballmer has known this for awhile. Remember his big, sweaty "Developers! Developers! Developers! Developers!" rant?

<comment><USER4> Never forget that Microsoft is at heart a languages company. They came from writing computer languages and detoured into operating systems. Frankly, they've always been very, very good to developers.

They've always known that the developers matter.

<comment><USER5> I still wish MS would ship windows with a usable console.

<comment><USER6> Windows 7 ships with PowerShell.

<comment><USER7> Windows 7 hasn't officially shipped yet.

<comment><USER2> I've been using Windows 7 for a month now as my primary OS. Works fine.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> The "API Basics" PDF doc states that you must a) have an API ID and b) limit your Queries Per Second (QPS) to 7/second.

'b)' sounds like a usage quota to me.

<comment><USER9> I don't think b) sounds like usage quota.

If you have an unlimited ride Metro Card, you can use it as many times as you want during the month but you won't be able to swipe it back to back to prevent abuse.

Similarly, 7 queries per second is a decent limit as it allows you to send more than half a million queries (Exact number = 604800 queries) in a day.

<comment><USER10> Total number of queries for a day doesn't really matter much if your peak traffic is above a per-second usage quota. That being said, I think the quota is pretty generous.

</comment></comment></comment><comment><USER11> Cool, but a pain for most (existing) commercial usage:

"On any page in which you display Bing results, you will only display advertising that we serve or provide."

Not sure how most sites could do that-- you could even read this jerkily as saying you'd be restricted from even advertising your own products on a page with Bing results.

</comment><comment><USER12> Microsoft seems to be on the roll (or should I say 'on the bing')

With the smooth loading bing and now the open API, Microsoft seems to be taking the battle straight to Yahoo and Google's court. This time Microsoft does seem to 'get' the future of search, and with Bartz screwing up the Yahoo open API program (with usage quotas and all) and Google just plan scared of releasing its own, the folks at Redmond seem poised for the next big leap in search.

I am not really a Microsoft fan, and use tons of great Google products, but search needs to move ahead, much faster than what Google is taking it.

</comment><comment><USER13> Nice to see. Google got rid of their non-Javascript API, IIRC, so Yahoo was the only one with a decent API.

<comment><USER14> Google has a JSON-based API: <http://code.google.com/apis/ajaxsearch/documentation/#fonje>

Its misleadingly named, hard to find, etc etc, but it exists. :/

</comment></comment><comment><USER15> Site currently seems bombed and google cache comes up empty. Anyone have a mirror?

Edit: Seems to work for me too now. For anyone interested, there's a bing developer site which has more extensive information.

<http://www.bing.com/developers/>

<comment><USER16> Came up fine for me.

</comment></comment><comment><USER17> I'm as much a fan of free, hackable APIs as anyone. But... how is this not a really clear anti-trust violation? It's one thing for MS to release a product that competes directly against Google's _free_ offerings. Quite another to use its revenue from other sources to undercut Google's _pay_ services. MS isn't competing on price here at all.

Maybe, I suppose, the argument would be that a target Google's size is so large that MS has no effective monopoly power to leverage. Google could just as easily (and, in many areas, is) fund free alternatives to MS software too. But still, this seems like a borderline-scary regression to some pretty ugly MS behavior.

<comment><USER18> Proving that someone is committing anti-trust violation against Google's search business is a very uphill task.

That the party you accuse is Microsoft makes only a little difference.

<comment><USER17> I would reply with something interesting, but clearly I've angered the downvote police, so I officially declare myself intimidated into submission.

<comment><USER19> Don't be fooled: I accidentally upvoted him because his retort felt sensible, but then I read his post, which rang of blatant trolling.</comment></comment></comment></comment>