The Most Important Word Ever - <AUTHOR> https://www.youtube.com/watch?v=PIJElPStJpg

<comment><USER2> Ever noticed that 'business guru' types tend to work on their own? Maybe that's why they're still in meetings at 11pm - they have far less bandwidth than a good team, so they need to work longer hours to keep up. I don't see that as a win.</comment>


As ER Wait Times Grow, More Patients Leave Against Medical Advice - <AUTHOR> https://khn.org/news/as-er-wait-times-grow-more-patients-leave-against-medical-advice/ <comment><USER2> > Moreover, ER wait times also increased for many during that time period: In > 2017, the median ER wait time for patients before admission as inpatients to > California hospitals was 336 minutes — or more than 5½ hours

Comparable stats from the UK: [https://www.kingsfund.org.uk/projects/urgent- emergency-care/...](https://www.kingsfund.org.uk/projects/urgent-emergency- care/urgent-and-emergency-care-mythbusters)

> By September 2017, the median waiting time had increased to 2 hours 28 > minutes, and 95 per cent of patients departed A&E within 7 hours of arrival.

So not only do Americans get to wait twice as long, but they have to pay for it as well? You have to pay for _ambulances_? Why is this not politicized more?

Mind you, where ever you go and however the system is run, queues will be worse in the evening especially at weekends. Some queueing is unavoidable and best dealt with by triage.

<comment><USER3> > So not only do Americans get to wait twice as long, but they have to pay for > it as well? You have to pay for _ambulances_? Why is this not politicized > more?

Emergency services are run by the cities, or sometimes the states. And that's a completely reasonable thing to do -- if you have a heart attack in Los Angeles, they don't take you to an emergency room in Boston. Local people should control local stuff.

So you're asking the wrong question. It's not a matter of what happens in America, it's a matter of what happens in California, or Los Angeles. Other US cities have free ambulance service or shorter wait times.

The local people can change their local laws whenever they like.

<comment><USER4> By your same argument, if a state is running the emergency services, what guarantee is there e.g. a heart attack in Los Angeles doesn't end up in Redding?

It would be possible to have emergency services organized nationally. I wonder if cities that overlap two or more states share emergency services. Seems like that would be ideal so that you'd always end up in the closest hospital.

<comment><USER3> > By your same argument, if a state is running the emergency services, what > guarantee is there e.g. a heart attack in Los Angeles doesn't end up in > Redding?

Well for one thing, because it's more than 500 miles away.

> I wonder if cities that overlap two or more states share emergency services. > Seems like that would be ideal so that you'd always end up in the closest > hospital.

Of course. It's the same as people who visit another state can still use the roads in that state. It's easier to cover a non-majority percentage of usage from out of state residents in exchange for implied reciprocity than to do a bunch of two-way accounting that in practice will generally just net to zero anyway.

The services are organized and funded locally because the local people are the ones with the strongest interest in them. Most of the people who use emergency services in Los Angeles will be people from Los Angeles, so they're the ones with the greatest interest in whether they're implemented competently and efficiently.

The problem with nationalizing things like this is that they have no real economies of scale, so all you're doing is adding unnecessary bureaucracy and creating wasteful arbitrage opportunities. Because then it's in the interest of the majority of states who pay less in taxes than they receive in benefits to inflate costs on purpose because it brings federal money into their state. California and New York -- and Texas -- have been getting screwed by this for years across a wide variety of federal programs that don't actually need to be _federal_ programs.

</comment></comment></comment></comment><comment><USER5> I had a serious complication of a medical problem a few years ago. After being bedridden and unable to lie flat for over 3 weeks, I developed a pilonidal cyst. This is a small abscess, usually from an ingrown hair, that expands into a cavity at the very base of your spine. I was in severe pain, had a visual lesion, and was almost unable to walk.

I went to an urgent care clinic. The friendly staff told me they did not take my insurance, but could do it immediately for $380 in cash. As I was hoping to find someone who took my insurance, I declined. I went across the street to the emergency room. The person at check-in heard "pain" and "back" and seemed to immediately decide I was a drug addict. 30 minutes later I talked to some decent check-in staff who told me they would give me surgery for it.

I ended up waiting in the ER for over 3 hours. When they finally did the surgery, it took about 10 minutes. Somehow, they messed up the billing. The charges were over $1,200 for the 10-minute surgery that the Urgent Care offered to do for $380. After moving out of state, I called multiple times to get them to properly charge my insurance. They failed to do so, and sent the entire bill to collections 90 days later.

<comment><USER6> If it is what I think it is, it I'd not a surgery but a simple procedure to drain it. It took about 10 minutes and they were able to do it in urgent care for me so it cost me just the copay for the visit - $35. I wrote in another comment that people don't know that they can use urgent care most of the time. I forgot about the issue you had, which is insurance. That's also a huge problem that you can only use certain facilities. I remember being stressed about it when a family member was in pain. The thing is that once I found one that works with my insurance and is 24/7 I already know where to go so I forgot about that hassle.

</comment></comment><comment><USER7> My friend knifed his baby's finger open at a backyard bbq in Mountain View and we had to wait six hours for a couple of stitches in Palo Alto on a Sunday evening starting at 9pm. Extrapolate that wait time to poorer areas, to people who don't have health insurance, to people who have other obligations...

<comment><USER8> an "urgent care" can also do stitches for injuries like this

<comment><USER9> Urgent care is closed at 9pm Sunday at least in MTV.

<comment><USER8> everything in MTV is closed after 9pm, any day of the week :)

</comment></comment></comment></comment><comment><USER10> In the UK, there is a phone service you can reach by dialing 111. There, a nurse can listen to you describe your issue and advise you if you need to go to hospital, make a next-day appointment with your GP, go to se the local pharmacist, or just get bedrest. My wife and I have used this a couple times and its great. It is something that I'd love to see brought to the US.

One aspect of the service that gives us a lot of piece of mind is that they can confidently and immediately tell you how much the NHS would charge you for their recommended course of action. I do wonder how you would build a similar system that could tell you what your medical insurance would cover and what your copay would be.

<comment><USER11> > I do wonder how you would build a similar system that could tell you what > your medical insurance would cover and what your copay would be.

This is literally impossible, by design, under the current system in the US. Neither the provider nor the insurer is able to tell you what something costs until they've had a few rounds at the dartboard to determine that.

<comment><USER12> That's absolutely not categorically true; if you have an American HMO like Kaiser they have price lists and cost estimators on their website. They also have advice lines exactly like the post you're replying to. I can also email my GP or message them through the app if it's less urgent.

<comment><USER6> Kaiser is very different than the rest of insurances. They have their own facilities and prices are generally known in advance. Any other insurance it's nearly impossible to know. You need to know if the facility accepts your insurance or not (in/out of network), if the service is covered, your copay, deductible, how much the place bills (note this is not how much they are paid), what's the price the insurance company negotiated with the place and actually will pay and bunch of other things. There's no single person who will be able to tell you the price that you will pay. And you need to know a lot and what to ask and who ask.

Unrelated to ER, I recently got charged almost $400 for a visit to a primary doctor that should cost $35. Had to go back and forth with doctor bill, hospital bill (apparently if doctor has an office in a hospital zone, they will also issue a bill, even though you don't really use the hospital) and the insurance company. I was going back and forth either side was either everything is correct and that's how much I should pay, or saying that the other side categorized it wrong. After attempting it multiple times. Eventually I gathered enough evidence that when talking to person from insurance she couldn't find excuse, then she suggested that I can submit request to review it. Why didn't they suggest that from the start. Based on information that I collected looks like the doctor's office and hospital categorized everything correctly (despite what insurance person said), I even had to figure out what the medical codes mean on the bill. And the issue is that the insurance company made a mistake.

I like Kaiser model it makes things easy to know in terms of billing, but I don't like that Kaiser give bonuses for doctors for minimizing costs. It encourages so called marginal care. For example you generally won't learn about new kind of treatments available from your Kaiser doctors. They will generally suggest them if you're not responding to the cheaper solutions. For example if you have an autoimmune disease they will prefer you to use DMARDs and NSAID type of drugs (even with their side effects) and won't mention biologics, which are much more expensive, but work much better and can often reverse the effects of the disease.

</comment></comment></comment></comment><comment><USER13> Question: What's broken about the economics of ERs such that more are not being created to satisfy demand?

My assumption is that people are unable to pay their medical bills, but I was wondering if there were other factors involved too.

<comment><USER14> In a lot of places, you need to ask permission before you're even allowed to build a hospital. I think that fact, and the process attached to it, helps keep the supply low.

<comment><USER15> Yup [https://en.wikipedia.org/wiki/Certificate_of_need](https://en.wikipedia.org/wiki/Certificate_of_need)

<comment> hakka-nyu-su That map shows California (which OP's article is about) as one of the states where CONs are not needed

</comment></comment></comment></comment><comment><USER16> They wait and wait and think and some point they realize how much the whole thing is going to cost. That makes them reevaluate priorities and they leave if they can. I bet things would be different if Health care had sane pricing. Would be interesting to compare these numbers to socialized health systems.

<comment><USER17> you wouldn't have wait times in a for profit environment.

Customers would self select between ER, Clinic, and primary care visits if all 3 were priced accordingly.

HOwever, since ER = Clinic = Primary visit in price, people go to the most- available choice. ER.

<comment><USER18> Hospitals are for-profit but with no price transparency. So they can make profit but their customer (patient) has no chance to make an informed choice.

</comment></comment></comment><comment><USER19> > 2017, the median ER wait time for patients before admission as inpatients to > California hospitals was 336 minutes — or more than 5½ hours.

We have a similar problem in Quebec (where healthcare is "free"):

> 35 per cent of patients in Quebec — one in three — waited five hours or more > for help in an emergency ward [1]

I was personally discouraged to receive public health care on 3 different occasions, after initiating the process myself. Waiting times were always the problem.

[1] [https://montrealgazette.com/news/quebec/quebec-has-worst- eme...](https://montrealgazette.com/news/quebec/quebec-has-worst-emergency- room-wait-times-health-and-welfare-commissioner-says)

</comment><comment><USER20> Not in the US, but a friend of my sister was bitten by a fox while she was abroad in Mexico, it didn't look like anything bad, but her friend convinced her to go to the ER to get it checked, the wait there was long and she ended up leaving after 3 hours of waiting. She developed rabies and was repatriated to France where she died a few weeks later. Nothing could be done because the incubation period had already passed.

Please have insurance, and don't give up getting checked because it doesn't look serious or you don't have insurance, and always schedule a follow up with you GP as the ER only address urgent things for until you follow up.

</comment><comment><USER21> This is specifically about California, with a smidgen of data nationwide for the US.

</comment><comment><USER18> I think if there were more primary care doctors people wouldn't go to emergency rooms. You shouldn't have to go to an ER if you have fever.

<comment><USER22> And 80% or more of what a primary care doctor does can comfortably be done by any decent nurse practitioner. We should be encouraging the training of many more nurse practitioners to take this load.

</comment></comment><comment><USER23> This is going to get a lot worse as boomers consume more and more healthcare resources.

</comment><comment><USER24> How does it compare to countries with more socialistic medical care?</comment>


Functional programming explained properly - <AUTHOR> http://poincare101.blogspot.com/2012/02/functional-programming-explained.html

<comment><USER2> I would add the following.

Just think of the word function for a moment, in an algebraic context. A function is a a relation (ie, a mapping from a set of things to another set of things) where each element of the domain maps to at most one element of the range. Now, the inverse does not hold: any given output might have several inputs that lead to it.

For example, f(x) = x^2 is a function because f(2) is always 4, no matter what end of story. f(-2) is also always 4, and that's okay.

In most languages where you use "functions" you can modify state as part of the function doing its thing. Modifying external state opens up the possibility that, if we are writing a function `func`, `func(A)` might somethings return B or sometimes return C. That violates the definition of a function.

This could happen if our `func` example mutates a variable that it relies on, alters a database, etc. If that variable, or that database, is used elsewhere in the program, you open the door for non-determinism. In other words, bringing in external state could very well mean that your function isn't a function at all, in a mathematical sense.

Sticking with mathematical functions means that your program is more deterministic. It means you can reason about the correctness of your program more easily. It means that you can write a series of reusable components which can be composed any which way without too much trouble, and thus refactoring and creating libraries is much easier.

Only at the "edge" of your program, where it absolutely must mutate the outside world in some way, should you violate this.

<comment><AUTHOR> I really like this, I'll incorporate in once I get a bit of time.

</comment></comment><comment><USER3> Minor nitpick: decoupling isn't the ability to test things separately— although it _allows_ you to do that. Decoupling is the minimization of a piece of software's dependence on another.

<comment><AUTHOR> Thanks for the feedback!

That was a slight "oops", sorry :)

<comment><USER3> No problem! Your post was pretty interesting. As someone who's never used Haskell ( _ducks_ ) it's nice to hear about its functional advantages.

If you're doing another post, it would be nice to see examples of a functional implementation of addNumbers.

<comment><AUTHOR> Sure, I'll do a post like that :) Seems like a good idea, thanks for giving it to me.

</comment></comment></comment></comment><comment><USER4> > You're probably saying "WHAT?!! How am I supposed to implement a counter > then?!", and that's solved entirely by the fact that you can use recursion.

Yes, true, but IMHO the author ought to have explained that in most cases the compiler turns this apparent recursion into more efficient code that doesn't recurse unless it must, so you get the best of both worlds -- a pure function in source, and efficient code for the machine.

<comment><AUTHOR> I refrained from saying this, because this isn't always true, and as graph reduction processors slowly get introduced, this is going away.</comment></comment>


Artificial Intelligence for Dummies - <AUTHOR> https://itbook.store/books/9781119467656 <comment><USER2> It's just an affiliate link wrapper</comment>


Why Apple might be the next RIM - <AUTHOR> http://www.vuru.co/blog/2012/04/12/why-apple-might-be-the-next-rim/

<comment><USER2> If this was "Will Apple be the next RIM?" you could just answer no and move on.

The rule is that headlines phrased as questions are answered with no.

We now need a similar rule for "Why <event that won't happen> might happen" headlines.

<comment><USER3> Will Hacker News be the next Geocities?

This article couldn't be more wrong.

</comment></comment><comment><USER4> Ludicrous. Apple is spread out over many more computer markets than RIM ever was.

<comment><USER5> I wouldn't say it's ludicrous but you're right. Apple would have to screw up really, really badly in order to go the same way as RIM.

</comment></comment><comment><USER6> Alternately: "Why vuru is probably trolling for page-views with baseless speculation"

Steve Jobs was a key figure in the history of our industry but it's not like he built the iPhone personally and the entire team didn't depart with him. In contrast, RIM has had bad management for many years and no track-record of successfully building a consumer product - Apple could get there but it's not going to happen quickly or with any plausible single mistake.

</comment><comment><USER7> With that title and given the first few HN comments, I did not bother reading it. However, I do have an opinion to share: IMO, a better subject would have been "Apple might be the next Sony, or not"

Comparing Apple with Sony makes way more sense to me than comparing it with RIM. Both are in e consumer market, the iPod is the next Walkman, and with some squinting, the iPod Touch is the next Playstation.

</comment><comment><USER8> I unsubscribed from the mailing list after this article. No compelling evidence (other than "Tim Cook is not a product guy"). Giving a time horizon or recent evidence on statements such as "Apple is a great company but realistically, can they continue like this ad infinitum? History says no." seems required to be taken seriously.

</comment><comment><USER9> That line makes as much sense as "Why Google might be the next Yahoo"

</comment><comment><USER10> RIM's current market cap: 7B

RIM's highest ever market cap (6/20/08 @ $145/share): 76B

Apple's current market cap: 580B

The comparison isn't even close, and that's just the financials. Take a look at the market segments each company covers, and you find a similar disparity in comparison.

Yes, Steve Jobs was a huge part of the vision of Apple. But he wasn't everything. Apple is successful because of how the company is run, and coincidentally, Tim Cook is a huge part of that. If you remember, 12 years ago Apple was a struggling company selling computers to designers, illustrators and some educational institutions. Since then, Apple has transformed itself to be the dominant high-end personal computer maker, the dominant high-end smartphone maker, and the dominant tablet maker in consumer electronics. They managed to grow and flourish a retail business model in a decade that saw the demise of retail as more companies shifted to online distribution channels (an effort led, coincidentally, by Tim Cook). They have more cash on hand than the U.S. government.

If anything, a better comparison would be Apple 1999 : RIM 2012. Except that RIM doesn't have a Steve Jobs-type product visionary to bring it back from the brink of death.</comment>


Developing Bug-Free Machine Learning Systems with Formal Mathematics - <AUTHOR> https://arxiv.org/abs/1706.08605 <comment><USER2> Finally, an excuse to learn to use theorem provers and include them in my research as an auxiliary tool!

Note that they claim performance similar to TensorFlow in CPU only. But a direct translation of this to Python TensorFlow code could run in GPU, and is probably easy to make. It wouldn't be proven, but it would be much more likely to be correct than the code you have constructed for your research just now.

Also as scribu states, this doesn't allow you to prove final goals of the system like "classify images with 95% accuracy", nor does it save you from insufficient or inaccurate data.

(Edit: added last paragraph, finished reading paper)

<comment><USER3> > Note that they claim performance similar to TensorFlow in CPU only. But a > direct translation of this to Python TensorFlow code could run in GPU, and > is probably easy to make. It wouldn't be proven, but it would be much more > likely to be correct than the code you have constructed for your research > just now.

They are wrapping unverified C++ code (Eigen) for the primitive kernels anyway, such as gemm, so AFAIK it could be extended to launch kernels on GPUs without any modification to the part in Lean that they proved correct.

Since most ML users are happy to trust TensorFlow, one could also wrap (unverified) TensorFlow and then use their approach to prove properties about real TensorFlow programs, e.g. that various model-transformations are sound.

<comment><USER4> Author here.

> They are wrapping unverified C++ code (Eigen) for the primitive kernels > anyway, such as gemm, so AFAIK it could be extended to launch kernels on > GPUs without any modification to the part in Lean that they proved correct.

That is correct. Our Lean development assumes that we have primitive kernels that we trust, and it is otherwise agnostic about how they are implemented. It would be straightforward to have kernels run on GPUs.

> Since most ML users are happy to trust TensorFlow, one could also wrap > (unverified) TensorFlow and then use their approach to prove properties > about real TensorFlow programs, e.g. that various model-transformations are > sound.

This is a great idea. There are a bunch of useful properties TensorFlow users could prove about their programs. For example, a user could prove that their TensorFlow program will never produce a NaN, or that a mutation operation is "safe" and won't corrupt the gradients (see [https://groups.google.com/a/tensorflow.org/forum/#!topic/dis...](https://groups.google.com/a/tensorflow.org/forum/#!topic/discuss/kdhnp35QJfs) for an example of unsafe usage). Moreover, since verifying specific properties of specific programs is much more routine than verifying algorithms, most of the proofs could be push-button.

To TensorFlow users reading this: what are some common errors you make that are annoying to track down, that we may be able to catch (or prove the absence of) using formal methods? If there is enough demand perhaps we will work on this next.

</comment></comment></comment><comment><USER5> Sounds cool, but how do you "state a formal theorem defining what it means for the system to be correct" when the task is classifying objects in an image, for example?

<comment><USER2> You can't, not yet. However you can specify the following:

>The main purpose of the system is to take a program describing a stochastic computation graph and to run a randomized algorithm (stochastic backpropagation) that, in expectation, provably generates unbiased samples of the gradients of the loss function with respect to the parameters.

which is pretty good, and can save you from errors in manipulating the math of your gradient to make it have less variance, and in implementing it.

</comment></comment><comment><USER6> This is the final state of tech (until general AI). Fully-proven infrastructure, AI-powered user level features.

</comment><comment><USER7> > Stochastic computation graphs extend the computation graphs that underly > systems like TensorFlow ... by allowing nodes to represent random variables > ...

Doesn't TensorFlow support random variables too? They even compare their performance to TensorFlow on a model with random variables.

<comment><USER4> > Doesn't TensorFlow support random variables too?

The paper doesn't explain this well, but although you can put random variables in TensorFlow programs, you cannot backpropagate through them. With stochastic computation graphs, you can differentiate the expected loss as long as the probability density/mass functions of the random variables are differentiable. One of the main benefits of stochastic computation graphs is that you can train with arbitrary, non-differentiable simulators as long as they only depend on the parameters indirectly though random variables.

> They even compare their performance to TensorFlow on a model with random > variables.

The naive variational autoencoder of Figure 2 cannot be trained in TensorFlow since the random variable depends on the parameters. However, this particular model can be reparameterized so that it doesn't depend on them without affecting the expected loss (Section 4.6) and the resulting model can be trained in TensorFlow.</comment></comment>


I visited my Circuit City's liquidation sale. Nobody was buying anything. - <AUTHOR> http://technologizer.com/2009/01/20/circuit-city-the-frenzy-has-passed/

<comment><USER2> It is just another sales tactic. Raise prices 200%, cut them 80%, wash, rinse, continue.

These scammers were shit when they were doing good. Some other company has or will buy their inventory of any value.

The worst travesty is that they stole everyone's money that had giftcards as they disallowed them last spring. Now _that_ is criminal. Good Riddance.

</comment><comment><USER3> circuit city stores don't officially close until march 31, 2009 (from a cc manager i know). that means no good deals until the last few weeks.</comment>


Haxe – Cross Platform Development - <AUTHOR> https://haxe.org/ <comment><USER2> I used to work with Actionscript and Haxe came from the guy who wrote Mtasc, so we were quite excited. We loved that you could access features of the Flash VM that were not available through Actionscript, but it never gained traction. Right now, Haxe is a weapon of choice for people building Smart TV apps and things. I think that Nicolas was working for Massive Interactive doing just this.

</comment><comment><USER3> The features look really promising. So what's the catch here ?

<comment><USER4> I can only answer this as someone who's looked into Haxe for a couple of years now versus someone who has actually made an application/game/website with it, but from what I can tell, it's really the 'good at most things, great at non' option for easy interactive, multi-platform development.

What you may not know, is that HaXe started off as an alternative to using Actionscript to build flash/flash-like projects, without having to use Adobe products directly. When the bell started ringing for everyone to get out of the Flash pool (helped a lot by Apple not including it in IOS), they sort of pivoted to being the open source version to Flash (OpenFL), which they used HaXe to build. (One of the things going in their favor was that they were one of the 1st tech stack that tried to do what flash did in a compiled language that included mobile and web targets, besides desktop. The only other ones I can think of that tried was Java and a bunch of 'compiled' js and html files into executables.)

Once they realized that they could just change the target of what they were cross-compiling to, they started adding other targets as well (started with swf and actionscript, then went Javascript, Java, PHP, C, Ruby and who knows what else). People started adding other things to it, such as IDE, game engines, and even Adobe themselves are re-purposing Adobe Animator to target OpenFL. And it grew from there.

Where I usually get confused and leave it all alone is that there is so much churn in that area, that it's hard for me to even begin pick a stack to work with. Apache Flex competes in a lot of what HaXe does, same as Apache FlexJS, Apache Cordova, Cocos2d, Dart/Flutter, Monogame, and so much more in the same area. It got to the point where even Unity and Unreal engine provides much of the same features, pretty much for free until you've hit a certain monetary limit (I think both are around 250k to 1mil, USD).

So, to answer your question again after I've bored you, the catch is that it's one of many (and I do mean many) options for you to choose if you're trying to target many platforms from one code base. It's decent on most all of them, and was one of the firsts to succeed, but depending on your particular needs, may not be the overall best choice for you.

<comment><USER5> Small nit, Haxe doesn't have the upper case X anymore...

One more caveat to add to the end of your note here... Actionscript was probably the biggest standardized language across all web browsers at one time. It's dead largely because of a business decision, and this left a lot of developers in the lurch. This will undoubtedly happen again.

Haxe is run by a group of developers that insists on keeping control of their tooling and means of development, regardless of what other platforms emerge. This always involves dealing with some rough spots and friction getting things to work initially, but in the long run it pays of with greater flexibility and peace of mind.

Full disclosure - Member of the Haxe compiler team

<comment><USER4> Thank you for clarifying about the developer's aspect of haxe.

Also didn't know about the x being lower cased now. :)

</comment></comment></comment></comment><comment><USER6> I worked with haxe a few years back - great development platform! I'll have to read up on what has changed...</comment>


Cbox – a new python package, convert any python function to unix-style command - <AUTHOR> https://github.com/shmuelamar/cbox <comment><USER2> I will be immediately putting this to use and possibly assigning an engineer or two to the task of cribbing from this to try to prototype something similar for Rust.</comment>


Facial Recognition for Pigs – China's Tech Firms Are Mapping Pig Faces - <AUTHOR> https://www.nytimes.com/2019/02/24/business/china-pig-technology-facial-recognition.html <comment><USER2> _The creatures outside looked from pig to man, and from man to pig, and from pig to man again; but already it was impossible to say which was which._

\-- George Orwell, _Animal Farm_

When pigs are surveilled to the degree as human livestock, they will have truly transformed into us and us into them.

<comment><USER3> That is a brilliant quote for the context, thanks!

</comment></comment><comment><USER4> Does it have to be the face? Just wondering if they could've used another combination of body parts with sufficient variation and use those as the "fingerprint" instead. Rather than "the bristles, the snout, the eyes and ears" specifically.

Or are faces evolved to be unique in (social?)animals and nothing else is as easy to tell apart?

<comment><USER5> This just conjecture, but isn't the body slightly more amorphous then the face? Body-fat and muscle can make someone, even a pig, look different but variables like the eyes, nose and ears generally stay the same (at least past puberty). We also have facial recognition technology already and it may be that it's easier to adapt to another mammals face than it is to work from the ground up again.

</comment></comment><comment><USER6> Just look at the barn. Pigs are smart creatures. How can a creature be happy in that barn? I had some of the best pork ever in Kauai where pigs roam pastures. Isn't that a better solution?

</comment><comment><USER7> Most smaller producers already recognize their livestock as well as family resemblance. If African swine fever does in fact produce a fever, wouldn't that be a better screening method? Like in an airport. Pigs are highly intelligent, and "tech" enabling them to increase or decrease barn temperature (up and down snout-pressed buttons) has shown to save money on heating bills.

</comment><comment><USER8> How long until we have thisisnotarealpig.com?

</comment><comment><USER9> > You're in private mode.

> Log in or create a free New York Times account to continue reading in > private mode.

It is the first time I see such a nag screen. Is there any firefox Add-on that could allow me a "stealth private mode"?

Meanwhile, I just disabled Javascript on this page, which works well enough (except for the images, it seems).

<comment><USER3> Tipp: I recently started using uMatrix with default-deny for everything except css/images.

It's remarkable how much faster most sites load (even compared to uBlock), and almost every site can be made functional in ~ 30 seconds by editing the settings in a nice grid view if it requires JS.

</comment></comment><comment><USER10> "You can't take a single picture of a pig," said Mr. He, who is trying to add to his database of more than 200,000 pig images. -Multiply by 400 million pigs, then imagine the emissions from these data centers!

<comment><USER11> I imagine the emissions are a tiny rounding error compared to the emissions of those pigs. Livestock and the fields to feed them are one of the largest contributors to climate change. If those servers improve efficiency at all that will easily offset their emissions

</comment></comment><comment><USER12> pigman

</comment><comment><USER13> Straight from yesterday's Joe Rogan podcast!

So this is the next step. First human-pig chimera hybrids. Now their population is so big that they need to develop facial recognition.

</comment><comment><USER14> This sounds like one of the (few?) classes of problems that blockchain can solve best.

Get every pig tagged and on the blockchain. Then a quick scan tells you where it came from, where it's been, and who else it encountered along the way.

<comment><USER15> Replace "blockchain" with "database" and everything you said still applies.

<comment><USER16> I'm no blockchain fanboy but I believe the distinguishing features are "decentralized", "permanent" and "verifiable". If you put that stuff in a database, someone can change the database.

<comment><USER17> If someone can change a database, then why couldn't someone change data before being entered into a blockchain?

<comment><USER18> That is still an issue but blockchain-ish tech solves the "double spend of pig". I.e. you can't sell the same pig to many slaughter houses.

<comment><USER19> Except when you own more than 30% of the pigs then you have a higher chance to double spend a pig

<comment><USER20> that is doubly true for the owner of the database,atleast with a chain you can tell when manipulation is going on(on a long enough timeline)</comment></comment></comment></comment></comment></comment></comment>


Did Germany experience industrial boom in 19th c due to absence of copyright? - <AUTHOR> http://www.spiegel.de/international/zeitgeist/0,1518,710976,00.html

<comment><USER2> China probably wouldn't be growing as quickly today if it strictly respected copyrights.

Copyrights favor established industrial producers because they hold the IP.

<comment><USER3> It is arguable that this has only become true in the past ten years. For a long time lack of IP controls was a big barrier to international trade for China.

<comment><USER4> I'm not asking this to be snide, or sarcastic, but...

Do you have a source for that? I'd be interested in seeing such a thing.

</comment></comment></comment><comment><USER5> The US had lax copyright early on. It makes sense for a net importer of IP. It's a great way to _catch up_. But what about the originators of the industrial revolution? Would they have done even better without copyright? I don't know, but the industrial boom in Germany isn't evidence of it.

An interesting present day case is the ACM charging for academic papers. Some papers are available from the author's website for free, but some are not. Although the fee is affordable (around $20-30), do publications that are free lead to better propagation and thus more/better research?

I think it's very hard to judge this, because I think what happens in practice is that unknown academics give away their papers - it helps them to get known. Whereas the ones that you _have_ to pay for are the massively famous ones with (eg) 700+ citations. Their knowledge is already out there in the community, and their reputation probably further promotes their research much more than the small fee retards it. In addition to this, you're probably better off reading a free review/summary/interpretation of the famous work than reading it in the original - so the ideas keep promulgating.

<comment><USER6> The ones that aren't on the author's website are mostly the ones whose authors aren't active on the internet at all. Of course, papers become more highly cited over time, and authors die and retire, so many of the most famous papers are in this state.

Traditionally, journals would send a few printed copies to the author so that the author could send them to people who wrote them asking for a copy, a custom that continues to some extent today. Putting the final version of the paper on your web site is simply an extension of this approach.

Copyright is pretty much irrelevant as an incentive for production of academic work. In nearly all fields, authors don't get paid by journals for writing papers. In many cases, in fact, they have to pay for the privilege of writing those papers. Academic books aren't net cash-flow negatives in the same way as journal and conference papers, but the total earnings per hour are very low.

In academic publishing, copyright has historically served as an incentive for _printing_ academic work. Given our new methods of printing, using laser printers and computer screens, that incentive is no longer relevant. The main issue today is to prevent the last copy of an old paper from being lost, and ensure that it can be found easily so that it can be copied. Libraries are better suited to these purposes than printing companies. Copyright in its current form is a serious menace to that kind of preservation.

Non-academic publishing may be a different ballgame, of course. I don't know.

</comment></comment><comment><USER7> Arguably the patent system in Britain also had consequences that slowed down industrialization. From this article (<http://mises.org/daily/3280>):

"During the period of Watt's patents [1775-1800] the United Kingdom added about 750 horsepower of steam engines per year. In the thirty years following Watt's patents, additional horsepower was added at a rate of more than 4,000 per year. Moreover, the fuel efficiency of steam engines changed little during the period of Watt's patent; while between 1810 and 1835 it is estimated to have increased by a factor of five."

<comment><USER6> Wouldn't you expect both efficiency and total capacity to increase exponentially in the first half of a sigmoid adoption curve without taking into account any exogenous factors? Today most electric power plants are still run by steam engines, so it's likely that that exponential increase is still continuing.

<comment><USER7> Electric power plants are run by steam _turbines_ today (invented by sir Charles Parsons in 1884). I don't think there are any steam _engines_ in industrial operation.

Regarding the logistic curve, yes, your point is valid in general; however, the article cited makes it clear that Watt's patent dramatically slowed down the adoption rate by delaying essential improvements for 25 years. In particular, the adoption of high-pressure steam (an idea Watt simply disliked) proved essential for locomotives and for improving the fuel efficiency to a level where steam engines were practical in more than a small corner of the British economy.

<comment><USER6> The steam turbine (invented by Hero of Alexandria in the 1st century BC, and improved dramatically since then by Parsons, among others) is a kind of steam engine. With regard to _reciprocating_ steam engines, I don't know of any in current use either, but I would be surprised if there weren't at least a few niche uses.

You are certainly correct about high-pressure steam being essential. Did Watt's patent make it illegal to develop high-pressure steam engines, or just uneconomic?

<comment><USER7> The (practical) steam turbine is one of the fundamental, yet unacknowledged, bases of our material civilization. Parsons based his intricate design on the equations of thermodynamics; he succeeded in a very complicated task where many others had tried, and failed. His work is about as many orders of magnitude more complex and demanding than Hero's aoelipile as a modern race car is compared to a spring-powered toy cart.

That said, I agree that the terminology is flexible and the steam turbine can be considered a kind of steam engine; it is, however, very different in its principle of operation from the Watt-type steam engine (which it displaced in the XXth century). Regarding high-pressure steam, as far as I know Watt's patent precluded anyone from using a condenser in their steam engine, which is an essential component. Thus only engineers affiliated with Watt himself were able to produce commercial steam engines during the 25 years he held the patent, and he refused to let them work with high-pressure steam (despite a good deal of interest).

For a more thorough, and much better documented, discussion of these issues, I recommend chapter 3 (Internal Combustion Engines) of Vaclav Smil's book "Creating the Twentieth Century".

<comment><USER6> It certainly is a very important invention, but I'm not sure what you mean by "complex and demanding"; you can build a perfectly good steam turbine with one moving part plus a high-temperature thrust bearing.

A condenser is not an essential component for a high-pressure steam engine. It can be useful (modern power-plant steam turbines use condensers because they're quite sensitive to lime deposits, so the water has to be expensively purified before use) but e.g. steam locomotives did not normally use them.

It is not the case that there were no non-Watt commercial steam engines built in England during Watt's patent; a good number of Newcomen-type engines continued to be built. But thank you for explaining that Watt refused to license his patent.

Thank you very much for the book recommendation! It sounds like a book I've been wanting to write. Maybe Smil has saved me the trouble.

It's interesting that reciprocating engines are quite common in the modern economy outside of the steam department. There are even commercial electric power plants driven by reciprocating engines. But they're internal-combustion.

<comment><USER7> The concept is relatively simple (once someone thought of it...), it's the execution that's difficult. (For a simpler example, let's look at breech- loading firearms: the idea appeared almost as soon as gunpowder, but it took until the 2nd half of the 19th century to achieve cheap, practical designs.) In the Parsons turbine, the shape of the components is much more complex than the piston plus cylinder of the Watt engine (see <http://www.leander- project.homecall.co.uk/turbines.html> for a diagram). All the little blades and such also need to hold up to high pressures and temperatures.

I'm not entirely sure about the condenser bit, but I do remember Smil addressing the issue with references and all. His books are quite amazing, it's quite a pity they're not better known.

<comment><USER8> Who is Smil?

<comment><USER7> Vaclav Smil - a professor who writes wonderfully detailed books about the history of technology, among other subjects.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Perhaps the RIAA can spin this into a campaign: "absence of copyright responsible for two world wars!"

<comment><USER10> Cancer is responsible. If only Friedrich Wilhelm I would have survived on the throne for more than 100 days, say a few decades.

<comment><USER11> Friedrich III, right? I was confused there for a moment.

<comment><USER10> He was the third King of Prussia with that name, but the first Emperor of Germany. So both numbers are correct in their context.

</comment></comment></comment></comment><comment><USER12> Very interesting article, especially in contrast with the English claim that the copyright was the key to the industrial revolution: <http://www.economist.com/node/16789318?story_id=16789318>

I would be cautious about explaining such complex event by a single reason, as alway there are many factors involved.

<comment><USER8> Actually, there are claims that patent monopolies delay the industrial revolution, rather than advance it.

Too bad the book in question isn't free to read, otherwise, I would be able to add more knowledge about the other side.

The abolitionists on the other hand, cheerfully made their work freely available when they can. They also happens to make a few bucks off of it too.

</comment></comment><comment><USER13> One could argue (and probably someone has) that the web boom of the past 10-15 years also benefits from weak intellectual property. Imagine the pace of progress if, for example, Experts-Exchange were able to sue Stack Overflow for cloning their idea, or Quora were now in litigation over Facebook Questions.

<comment><USER14> ... or if there were no View Source browser option.

</comment></comment><comment><USER15> It does seem that the faster knowledge can spread, the faster industrial and technological development happens.

One would think, then, that economic strength is related to not how much money publishers make - but to how thoroughly knowledge is distributed throughout the country.

Given this, could a valid economy be built where there are no copyright laws? Where writers, researchers and other creators of works to be published are paid by how many people read them - but not directly by the people who read them?

Getting the government involved would likely lead to rapid politicization of what gets published. What entity would step up to fund this, then?

In other words:

If spreading knowledge without the encumberance of copyright law enhances the economy and makes everyone richer (except, presumably, the artist whose work will be copied), what system could be put in place to make sure the artist/researcher/scientist/inventor is compensated for his contributions to the growth of the economy?

<comment><USER8> _If spreading knowledge without the encumberance of copyright law enhances the economy and makes everyone richer (except, presumably, the artist whose work will be copied), what system could be put in place to make sure the artist/researcher/scientist/inventor is compensated for his contributions to the growth of the economy?_

In the past, there has been example of American publishers paying more money to British authors than they receive in royalty in their own land even though USA didn't recognize foreign copyright at the time.

Even though there was no copyright, the same thing happened to America as it did to Germany. There was increased literacy built on the back of (in some case well-compensated) British authors.

I am sure artist/inventors/researchers/scientists can find business models that substain themselves.

<comment><USER10> It should have been relatively easy to transplant the British literature to America. Do you know how much transfer there was to Germany?

<comment><USER8> No. The book I read contain case study on British-America copyright regime but nothing that I can remember dealing with Germany-British copyright regime.

</comment></comment></comment></comment><comment><USER11> If this is indeed true then there is an ironic aspect to it. The continued non-existence of a German state until 1871 – here presented as the reason for the lack of effectiveness of copyright law in the German states – is one of the canonical reasons why the German states were lagging behind in their economic development. (It's hard to be all that successful when your company has to ship its product through half a dozen states [+] – all with customs and different laws – just to get it from Cologne to Munich.)

It's certainly nice to see attempts at explaining why Germany caught up with and to some extent even overtook England. I don't think that the canonical explanations (which to me always seem to include a lot of handwaving) are very convincing.

[+] Map: [http://upload.wikimedia.org/wikipedia/commons/thumb/e/e9/Deu...](http://upload.wikimedia.org/wikipedia/commons/thumb/e/e9/Deutscher_Bund.svg/2000px- Deutscher_Bund.svg.png)

<comment><USER16> It also doesn't cover correlation/causation. Did the book boom cause their industrialization, or did the mass industrialization cause the book boom?

<comment><USER17> It seems far more plausible that there was an exogenous factor causing the book boom in Germany: the number of Germans that actually knew how to read

The article hints at this when it suggests a German earned more in royalties (without effective copyright) for a treatise on leather tanning at the beginning of the century than Mary Shelley did for Frankenstein. Either UK publishers were exceptionally bad at maximising revenue (or sharing it with authors), or there was a much greater demand for books in Germany which had little to do with the supply of cheap copies

A highly plausible explanation is that German appetite for reading was driven by compulsory state-sponsored primary education, contrasting with the part- time, parochial education available in the UK at the time.

Despite low literacy rates the UK did a pretty impressive job of industrialising in the 20th century; to argue otherwise is to ignore the rate of absolute progress in favour of dubious relative metrics in the manner of Wired's recent "web is dead".

<comment><USER11> Oh, the UK's industry was and still is impressive. But the German states were far, far, far behind in the 19th century. It's just surprising that they could catch up at all.

<comment><USER18> It's not really that suprising. Industrialization originated in the UK, and emerged gradually from the economic and cultural situation there without any intentional design. When the Germans began industrializing, the UK's industry was mature and well-developed, which provided a very detailed practical example to reference.

19th-century Germany and Japan and modern China have all had the ability to work directly toward a goal, rather than having to wait for industrialization to emerge naturally from within their own economies (although if they had, it would probably have produced a set of customs and practices much more suited to their own cultures and economic conditions).

</comment></comment></comment></comment></comment><comment><USER10> German original: <http://www.spiegel.de/spiegel/0,1518,709761,00.html>

<comment><USER10> With an interesting alternative title.

<comment><USER19> What is the alternative title in english?

<comment><USER10> German: Explosion des Wissens

English: Explosion of Knowledge

The title itself isn't very interesting. The change is.

</comment></comment></comment></comment><comment><USER20> A superb book on the economic history of intellectual property legislation around the world:

[http://www.amazon.com/Lever-Riches-Technological- Creativity-...](http://www.amazon.com/Lever-Riches-Technological-Creativity- Economic/dp/0195074777)</comment>


Show HN: Jugggla.com – Multi-dimensional Column-based ToDo List - <AUTHOR> http://www.jugggla.com

<comment><AUTHOR> Jugggla is a simple Trello-like ToDo list with column layout, but with one interesting twist - it lets you slice and dice your tasks across different Dimensions. Eg You can view your tasks in columns by When (Today, Tomorrow, Someday etc), grouped by Why (Business, Personal, For Fun...).

You can customise the dimensions too - so for example on a software project you could add 'Who' as a dimension if you wanted to view tasks by who they were assigned to, maybe even broken down by Business Value (Bug, Feature, UI).

It also does a shuffly animation to switch between the different views, which we think is pretty cool :)

Does this have a place in the world?

</comment><comment><USER2> Very cool. Love the animated pivot.

</comment><comment><USER3> Love the pivoting</comment>


Everything that can go wrong with Windows Phone 7 update does - <AUTHOR> http://arstechnica.com/microsoft/news/2011/02/everything-that-can-go-wrong-with-windows-phone-7-update-does.ars?utm_source=rss&utm_medium=rss&utm_campaign=rss <comment><USER2> A little unfair. A lot more could be going wrong (it could be bricking every phone, for example). And to be honest, while the article seems to think the first update should be the least likely to have a problem, for me the first update is where I _will_ cut them some slack - this is a massive distributed update process that has never been tried before in the wild. Any of us real developers know that it's incredibly hard to actually test a process like this completely....

<comment><USER3> Am an embedded systems developer, and have dealt with similar updates before. I think the author is fair in expecting proper testing since there weren't too many variations to handle. Firmware upgrades aren't too complex, especially when you have h/w spec lock-downs. You just need to build in the right safe guards, and build a culture of thorough testing. This looks like a typical bureaucratically executed project with time+cost deadlines to meet, and narrow-minded bosses to please.

</comment></comment><comment><USER4> What this article points out is that MS has the toughest phone update process in the industry. And for all the whining people do with Android, they may have surprisingly got it right. Let me explain.

Apple's process is pretty easy. They own the phone, firmware, software, etc... It's easy for them to test and roll out. Everyone knows this.

Now Android went with a completely different approach. We give you the OS, now you own everything else. The OEMs have to ensure that any update works on their phone. This is great for Android for two reasons: (1) The OEMs COMPLETELY own testing each new build of Android. Google doesn't have to think about Gingerbread, except for systemic issues. And (2) if there are issues on a given phone, it's not Google's fault -- it's the OEMs.

MS is in a rather horrible position of delivering the OS directly to the phones thus having to test them as they are responsible for failure.

One big problem that comes up here is imagine you have one phone where the update just doesn't seem to work. Are you going to hold up all of the other phones just to get that one phone working?

If MS pulls this off, kudos to them. But I don't envy them. With that said, they pulled it off in the PC market, but that market built itself around MS- DOS, rather than MS-DOS coming out the gate with support for multiple manufacturers.

<comment><USER5> The only thing I would quibble with is: "This is great for Android". I think you mean "this is great for Google" or even "this makes it much easier for Google".

Assuming "great for Android" means "makes Android a better and more popular platform" -- I think that it will simply lead (indeed, has led) to horrendous fragmentation.

<comment><USER4> Yes, great for Google would be more accurate.

</comment></comment></comment><comment><USER6> I have an Omnia 7 and (to my relief) the update installed without a hitch. So it's not affecting all handsets.

</comment><comment><USER7> Any HN readers experiencing these problems first hand?

</comment><comment><USER8> Update went fine on an unbranded HTC Trophy for me, although having to deal with the Zune software is a minus.

<comment><USER9> Really? To me the Zune software is about 8 steps beyond iTunes.

The UI is great, lots of nice touches, looks modern, it's fast. I can drag music and such to my phone even if I'm using someone else's Zune software.

<comment><USER10> I find both of their UIs arbitrary and confusing, but at least Zune is prettier, I guess.

<comment><USER11> Is there any such thing as a non-arbitrary UI?

<comment><USER10> Fair point. I guess arbitrariness is like intuitiveness - it describes an individual's experience more than any objective characteristic of the software.

</comment></comment></comment></comment></comment><comment><USER12> I don't see this as the game changer the author makes it out to be. Remember that Microsoft is in this for the long haul.

The Xbox was plagued with problems in the early years but MS stuck with it; now it's one of their most profitable divisions.

</comment><comment><USER13> On an LG (on AT&T) and the update is not available.

<comment><USER14> Contrary to popular belief, sometimes a delay in releasing updates really _is_ a feature.

The article is hilarious on this point. "This just in! OS update kills phones, curdles milk, terrifies children! Also, users might be angry that they're not getting it right away!"

By the way, I shouldn't need to say this, but the plural of a terrifying anecdote is not data. Every upgrade ever pushed breaks _something_ for _someone_ , and the noise from one failure sounds louder than ten thousand successes. We'll see if this dire emergency still looks as bad three days from now when more reports are in.

<comment><USER15> > I shouldn't need to say this, but the plural of a terrifying anecdote is not > data

I hear this repeated a lot, and I think people parrot it without really understanding what they say. I'm not saying that this particular article is presenting properly sampled data, but in reality, a lot of social sciences collect their data by sampling a population and pulling together a plurality of "anecdotes".

That's basically the definition of data. An anecdote _is_ data. Whether or not it's statistically significant depends on the plurality, and sampling procedures, but to call it not "data" is quite unwarranted.

If you believe in western medical science, then you had better believe in anecdotes as data, because to this very day, medical journals report single case studies as data and evidence for dissemination across the medical community.

</comment></comment></comment><comment><USER16> Just wow. Fire the entire mobile division and get out of the market; you're cursed and/or hopelessly incapable of executing properly on anything in the space.

<comment><USER16> Thanks for having the courage to disagree through mods rather than comments.

And thanks again for the continued cowardice.

<comment><USER17> What is there to disagree with? There's effectively no content to your comment. "Fire them all" is not a solution to _any_ technical problem.

<comment><USER16> Actually, my solution was to fire the whole division AND get out of the market.

And this isn't a technical problem; it's a process and culture problem. MS almost certainly has the technical and financial resources to have prevented this. The fact that they didn't points to an utterly dysfunctional company. Getting out of a market that they're rather obviously too hidebound or screwed up to compete in, is definitely a solution.

<comment><USER18> Yeah, like they got out of the game console market when they were getting red rings of death. Or that time Windows ME was complete and utter crap, and they completely got out of the operating system market. Or that time they did something else wrong, and instead of firing everybody and getting out of the market, they learned from their mistake, came back, and fared very well or perhaps dominated it.

Microsoft, for all their power and ability, are not remotely above mistakes. They also do a pretty decent job of learning from them. I don't know of a home that doesn't have an Xbox 360 in it, or a home that doesn't have some installation of Windows in it.

Sure, it takes them awhile to hit their stride, but the worst thing anybody can do is discount them as a strong competitor, in any market they're in.

<comment><USER19> Cripes, really? Windows I'll give you, but Xbox isn't THAT popular.

<comment><USER20> I don't know if you're trolling, but Xboxes are one of the top selling consoles. See [http://www.kokeytechnology.com/gadgets/xbox-360/xbox-360-vs-...](http://www.kokeytechnology.com/gadgets/xbox-360/xbox-360-vs- playstation-3-ps3-sales-xbox-360-wins/) for a random example.

<comment><USER21> Not necessarily disputing your point but those figures are for 2008.

Current sales figures are roughly 50m worldwide sales for the 360, 48m worldwide for the PS3 (having been available for a year less), 85m sales for the Wii. For reference worldwide sales for the PS2 are currently 150m (and still selling).

All figures for Dec 2010 / Jan 2011. Worth noting that if those figures don't tally with what you see around you, the Xbox360 is way bigger than the PS3 in the USA (18m to 10m I think), the PS3 either equals or beats it in all other markets (notably Japan and Europe).

So yes it's "one of the top selling consoles" and 50m units isn't exactly chopped liver, but it's pretty much third equal in the market. Also worth noting that the whole Xbox division has lost massive amounts over all time (though it's now profitable, it's never recouped the original investment).

But I would agree with the point that while they take time to hit their stride, they do get there and I think Kinnect is a good example of the fact that they're now executing pretty well in this space and indeed innovating which isn't usually a word you'd associate with Microsoft.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> Lest you thought they had changed their ways.

</comment><comment><USER23> Ars Technica cannot be taken seriously when it comes to Microsoft. It's like FOX News reporting on Obama.

</comment><comment><USER24> Count your blessings if it only bricked a handful of phones and forced users to fiddle with their devices to get them working again. At least it didn't install Windows Phone 7 Genuine Advantage.

</comment><comment><USER25> Something tells me that the author doesn't really know what he's talking about.

> And because every phone is running the same software, well, it should all > just work, shouldn't it?

As we all know, an operating system is simply software. It doesn't interact with hardware and, if it did, the hardware is all completely identical, right? There's absolutely no difference between any of the WP7 phones on the market.

> The company was non-specific about the purpose of the update; it's not the > copy-and-paste update that will be shipped next month, but rather an update > to somehow improve the update process.

It's a test update, one whose sole purpose is to help Microsoft work with the carriers to figure out how to roll out updates. It's not like remotely updating hardware is a trivial problem. It's better to have a test update fail than a functional update fail.

<comment><USER26>
          An operating system is simply software. It doesn't
          interact with hardware and, if it did,  the hardware
          is all completely identical, right?

No offence, but that's the stupidest remark I've ever read.

And btw, hardware is almost never completely identical. Take 2 pieces of hardware built after the same spec by the same factory, and under certain conditions you may find them exhibiting different behavior. Hardware is not as predictable as software. It's the job of the operating system / drivers to make hardware predictable.

<comment><USER27> _No offence, but that's the stupidest remark I've ever read._

Pro tip: that's one of the key indicators of sarcasm.

<comment><USER26> If it is sarcasm, then sorry.

It's still winter, there's a blizzard outside and my sarcasm detector is malfunctioning. I wish for spring to come, but it will take another 20 days according to the latest forecasts :(</comment></comment></comment></comment>


Rabbit starvation - <AUTHOR> https://en.wikipedia.org/wiki/Rabbit_starvation <comment><USER2> A paper I co-authored about the possible optimal diet of late upper paleolithic humans in the South West of France showed that the primary constraint on their diet was fat. It was a long time ago, but as I recall the prevalent meat was roe deer, and that's very lean. Solving the linear programming problem for the nutrients showed that they needed nuts to get the fat content.

<comment><USER3> Any chance for a link? I have a friend doing research in roe deer and she might find it interesting :)

(I did try to google it but didn't manage anything)

<comment><USER2> The paper doesn't contain all the details, and the paper is only available via library loan or a scribd link. I'm checking to see what we said in the published paper about fat content, but I suspect it won't be useful. It was originally a paper presented at a symposium in Oxford in Feb 1985, and it was not well received, so we didn't pursue the details.

I might be able to provide screenshots of the paper for your friend to skim, but I suspect it won't be relevant. Email me - contact details in my profile.

<comment><USER3> Ah thanks, I wouldn't want to inconvenience you it was just to tell her something along the lines of : "Hey did you know roe-deer would be the main source of protein for early hom(inins?)"

It's kinda sad how some not-so-old knowledge has essentially been lost already (as in, if it's ungooglable it's practically lost)..</comment></comment></comment></comment>


Why is it so difficult to count dead people? - <AUTHOR> http://www.bbc.com/news/world-41038987 <comment><USER2> Because they don't raise their hands when asked to.</comment>


IPhone turns five today: a smartphone launch worth remembering - <AUTHOR> http://www.engadget.com/2012/01/09/iphone-turns-five-birthday-apple/

<comment><USER2> This article doesn't really answer why the launch is worth remembering. It does ask us to imagine a time before smart phones, though.

<comment> mkr-hn It showed the rest of the smartphone market that you could get a lot of people to buy something if you make it bland enough and flood every media outlet with marketing. Some day someone will create something novel, and Apple will be credited for keeping the market afloat for them.</comment></comment>


Say hello to x64 Assembly, part 1 - <AUTHOR> http://0xax.blogspot.com/2014/08/say-hello-to-x64-assembly-part-1.html <comment><USER2> Does anyone know what's a good macro-assembler these days? The article recommends NASM, but I don't know if it's comparable to MASM for larger, more complex projects.

I rather fancy getting back into writing asm, just to sharpen that skill. I haven't really written any since MASM 6.x on DOS, 20-ish years ago. I actually found it quite enjoyable and it's surprising how complex an application you can write from scratch in assembly without it becoming unmanageable, so long as you get into the right mindset and make effective use of macros.

Of course, any significant piece of assembly code is likely to contain considerably more bugs than just about anything else of the same complexity. You'll also experience a lot more segfaults during development than perhaps most are comfortable with, but there's something rewarding about controlling precisely what the machine is doing at that level. This is especially true if you manage to find a novel solution that just wouldn't exist when the hardware capabilities are abstracted away by a high level language.

In the same way that everyone should learn a Lisp to think in terms of ASTs and code-as-data, everyone should write at least one whole application in assembly just to appreciate how the hardware really works. Also to see how often there are _many_ ways to solve the same problem (especially with an x86 instruction set), sometimes with _wildly_ different performance characteristics.

<comment><USER3> _everyone should write at least one whole application in assembly just to appreciate how the hardware really works_

Unfortunately, with out-of-order execution and instruction-level parallelism, I doubt learning assembly teaches you much about how the hardware really works.

Edit: To the downvoter, care to comment?

<comment><USER4> Microarchitecture doesn't change the fact that the instructions in your program - the ones that you can work with - still have the same programmer- visible behaviour (except perhaps being a little faster.)

<comment><USER3> I don't dispute that. I'm saying the model that you learn from learning assembly is very different to what the hardware is doing.

Concretely, learning assembly, you might assume each core has a set of physical registers that correspond to the registers you see and that isn't the case.

</comment></comment></comment></comment><comment><USER5> I came across Intel's intro to x64 assembly when I was looking for some information on working with wide characters on 64bit (I seem to recall there were some new instructions introduced for that, I'm guessing one would probably be better off using libicu to parse eg: utf-8 into some form of 16-bit characters first, though?). Anyway, nothing on wide characters, but essentially a work-a-like hello-world for Microsoft Windows and MASM:

[https://software.intel.com/en-us/articles/introduction- to-x6...](https://software.intel.com/en-us/articles/introduction- to-x64-assembly)

</comment><comment><USER6> Being able to read x64 assembler even if you can't write it is great for debugging strange issues.

<comment><USER7> Javascript is the assembly language of today. For debugging purposes you're better off with Javascript.

<comment><USER8> Not everybody targets all their code for the web.

<comment><USER9> You mean there's code... not on the web?!

</comment></comment></comment></comment><comment><USER10> Excellent! Just 2 days ago, somebody here was complaining about shortage of asm programmers, and I suggested them that I'd personally be interested in a hello world x86_64 tutorial to rekindle my interest in asm...and today I see this posted! Exactly what I wanted, thank you.

<comment><USER11> I still don't understand why people who want to learn amd64 assembly won't read x86 tutorial. I write both x86 and amd64 assembly from time to time, and I don't think there are anything that make x86 tutorial/manual not applicable to amd64.

Sure, there are differences: register name, C ABI convention, system calls, memory modes, etc. But those information can be find easily in references. And you need reference for x86 anyway. Otherwise all mechanisms are the same.

<comment><USER12> It's a bit of a catch-22: you can't know that there's not much different between x86 and x86-64 until you understand both. I guess asm newbies have some kind of mistaken idea that x86 is irrelevant and not worth their time learning (even if it were completely dead in the wild, which it absolutely isn't, you still need to know it truly understand the architecture); I've tried to post older x86 and ARM assembly language guides, much better written and more in-depth than this article (no offense intended to the author), and the only comments I get are along the lines of "this is old, it doesn't even cover x86-64/ARM64."

</comment></comment></comment><comment><USER13> Thanks for the writeup. I'm going to try it one of these days when I get a break from work/startup. I ordered a few books recently and have been tinkering with writing an OS....got as far as writing a bootloader and then switched gears into learning ASM.

I bought Peter Norton's Assembly Language Book for the IBM PC. This book is pretty awesome and so relevant even 25 years later!! It covers the basics really well and stops at 386 (the latest proc then) so I don't feel inundated with hundreds of CPU architectures. Yes, I'll eventually get to those.

The other two books (in case anyone else is interested): X86 Assembly Language and C Fundamentals by Joseph Cavanagh. Operating Systems Design and Implementation (3rd Edition).

Also, while tinkering with ASM I decided to install MSDOS since the ASM book uses Debug.exe and I couldn't seem to find it for newer OS's. While looking to download MSDOS, I discovered the source code for MSDOS 1.1 & 2.0 @ [http://www.computerhistory.org/atchm/microsoft-research- lice...](http://www.computerhistory.org/atchm/microsoft-research-license- agreement-msdos-v1-1-v2-0/).

</comment><comment><USER14> The code doesn't render with links2. Does it rely on javascript?

<comment><USER15> Yup- they're gists. I'm pretty sympathetic, setting up pygments, etc., is sort of a pain.

</comment></comment><comment><USER16> desertmonad has a gist with 32bit and 64bit hello world's for osx. [https://gist.github.com/desertmonad/36da2e83569bc8b120e0](https://gist.github.com/desertmonad/36da2e83569bc8b120e0)

</comment><comment><USER17> Another great resource, albeit for x86 rather than 64 [http://savannah.nongnu.org/projects/pgubook/](http://savannah.nongnu.org/projects/pgubook/)

<comment><USER18> It isn't nearly as hard to find x86 guides as x86-64 guides.

<comment><USER19> That's why i started to write it :)

</comment></comment></comment><comment><USER20> You guys might enjoy this [http://www.pentesteracademy.com/course?id=7](http://www.pentesteracademy.com/course?id=7)

</comment><comment><USER21> Its funny after so many years Code is still called Text in assembly.

<comment><USER2> That's not the way I remember it in MASM/DOS. I think it's a Unix-specific thing.</comment></comment>


GitHub Trip Report - <AUTHOR> https://fossil-scm.org/forum/forumpost/536ce98d85 <comment><USER2> This is a pretty interesting writeup, even though I don't necessarily agree with everything. Makes you think, at least.

I've been out of version control for a bit, and GitHub itself for quite a bit longer, but this part was interesting to me:

> Because: It isn't really about Git anymore. GitHub used to be a Git > repository hosting company. But now, they are about providing other software > development and management infrastructure that augments the version control. > They might as well change their name to Hub at this point.

Just for added color: starting around 2010 or 2011 or so (around when we added Subversion to GitHub), we had a pretty solid idea that version control wasn't "the thing". Mostly because Mercurial was a strong alternative, and there always felt like there might be something new in the wings that could dominate in the next few years. Version control felt really dynamic, and deeply susceptible to change. And if something was better, we'd totally ditch Git for the new thing. The name was a bit of a misnomer, from that perspective.

I think that changed over time — I had a hell of a time trying to get movement on basic version control improvements back in 2014 — and now they're clearly much more about the ecosystem rather than version control itself. It's where the money is, of course, but it's also where the bigger innovation is, at least for the time being.

I think the author is right to say that Microsoft is targeting a different area than version control specifically, though you could argue if the outcome of that is good or bad. It's certainly different, though- they're especially growing headcount right now, and the company makeup is wildly different than what many customers tend think it is today, imo.

<comment><USER3> > Because: It isn't really about Git anymore. GitHub used to be a Git > repository hosting company. But now, they are about providing other software > development and management infrastructure that augments the version control. > They might as well change their name to Hub at this point.

I agree fully, but the one "feature" missing from drh's analysis is GitHub's social aspect. Getting code out in front of people and allowing them to interact with it (directly, via commits and PRs, or indirectly, via issue comments) as a feature of a social network is their differentiator.

GitHub's choice of git wasn't germane to building a social network: GitHub could have been successful using svn, excepting that git was ascendant at the time.

Fossil's feature of an integrated web server is an anti-feature to GitHub; it defeats the purpose of having a centralised "Hub."

<comment><USER4> ChiselApp.com provides a similar "Hub" for Fossil and it still serves a useful function in the Fossil community -- somewhere to host your Fossil repos.

I've been thinking about adding CI/CD support and other tooling, but the CPU resources required would be cost prohibitive.

<comment><USER5> I would love to use Fossil, but git is too entrenched. The only thing that would allow me to use it right now is basically automatic, two-way migration between git and Fossil, so I can use it locally and other devs can use Git, and we can all still use GitLab for the CI, etc.

Unfortunately, this seems pretty hard to do, so I'm afraid git is too powerful. I absolutely detest its porcelain, but what can we do?

<comment><USER4> Fossil can be configured to do a bidirectional sync between git [0], with the exceptions noted here [1] -- but it may not be a good idea [2] and I've never set it up.

[0] [http://fossil-scm.org/home/doc/trunk/www/inout.wiki](http://fossil- scm.org/home/doc/trunk/www/inout.wiki) [1] [http://fossil- scm.org/home/doc/trunk/www/mirrorlimitations.m...](http://fossil- scm.org/home/doc/trunk/www/mirrorlimitations.md) [2] [http://fossil- scm.org/home/doc/trunk/www/mirrortogithub.md](http://fossil- scm.org/home/doc/trunk/www/mirrortogithub.md) "Notes" section

</comment></comment></comment></comment></comment><comment><USER6> Maybe i'm crazy but i find it completely unremarkable that a GitHub strategy session leaves core git completely alone and instead focuses on improving the ecosystem around it.

<comment><USER7> This doesn't surprise me in the slightest. Looking at GitHub product changes over the last few years (or even GitLab product changes), the core git components have been largely untouched. In fact I'd argue that the core git part of GitHub hasn't really changed since ~2-3 years into the company.

This makes sense, because GitHub doesn't add value in "improving" the git part. Anyone can run a git server, and git itself doesn't really have much else to it.

GitHub adds value in all the places around it. Collaboration, process, teams, communication, code review, security. These are things that most people using git will need, which are better when integrated or close to their version control system, and things that git doesn't address.

As a GitHub user, I'm glad that this was what they focused on.

<comment><USER8> I'd be less generous and say outright that GitHub benefits from git being a bad tool that NEEDS an external ecosystem to make it usable.

Improving git itself goes directly against their interests.

<comment><USER9> Many of the things that GitHub adds are not things I see being part of Git.

</comment></comment></comment></comment><comment><USER10> > Surely a better approach is to record the complete ancestry of every check- > in but then fix the tool to show a "clean" history in those instances where > a simplified display is desirable and edifying, but retain the option to > show the real, complete, messy history for cases where detail and accuracy > are more important.

This is one thing (but not the only thing) that I intensely dislike about git vs bzr. Loglevels are not particularly new and can be applied so directly to the VCS log that bzr log has a level option.

</comment><comment><USER11> In case people are unaware, drh is Richard Hipp, aka the author of SQLite and Fossil.

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

<comment><USER12> Non-mobile: [https://en.wikipedia.org/wiki/D._Richard_Hipp](https://en.wikipedia.org/wiki/D._Richard_Hipp)

</comment></comment><comment><USER13> His critique on Git rebase is spot on:

[https://www.fossil- scm.org/fossil/doc/trunk/www/rebaseharm.m...](https://www.fossil- scm.org/fossil/doc/trunk/www/rebaseharm.md)

<comment><USER14> The moralising about it doesn't make much sense. In other professions, it's not "lying" or "dishonorable" to present your work in the most clear and understandable way to others, it's a basic condition for entry. I don't see how software's any different.

We had a proposal around commit standards at work recently: we came to the conclusion that rebasing your private branches and squashing out irrelevant commits is the recommended flow, to make reviews easier.

<comment><USER15> > _In other professions, it 's not "lying" or "dishonorable" to present your > work in the most clear and understandable way to others, it's a basic > condition for entry. I don't see how software's any different._

That's because you joined the "it's a story" camp without noticing. If you instead view git history as a sort of gentlemen's _audit log_ , then "refactoring" it is indeed both lying and dishonorable. And in no other profession it would be OK to mess with something used for review / audit purposes.

Personally, I'm in favor of the history/audit log view, because you can't predict today what information you may need in the future, and refactoring git history throws away a lot of historical context.

<comment><USER16> Not GP, but _I 'm_ certainly in the story camp. My commit history is not an audit log, it's documentation about the choices I made while writing my code, and a tool that helps me combine relevant parts.

In fact, I'm sure that you're lying too: every time you Ctrl+Z in between commits, you're removing parts of your audit log. Choosing when to commit is telling a story.

(Unless Fossil/whatever system you're using stores every character you ever type - I'm not familiar with it.)

Edit: To use an example from the article:

> Yet, sometimes we come upon a piece of code that we simply cannot > understand. If you have never asked yourself, "What was this code's > developer thinking?" you haven't been developing software for very long.

With my commit, I'm _telling_ other developers/my future self what I was thinking, rather than having them try to figure that out by themselves from my code. The assumption there is that I'm better at explaining my thinking than my code is.

<comment><USER15> > _In fact, I 'm sure that you're lying too: every time you Ctrl+Z in between > commits, you're removing parts of your audit log. Choosing when to commit is > telling a story._

And I disagree here. The way I view it, my editor is my sandbox, I keep playing in it until I have something that I want to enter into record. When I commit work, I enter it into record, with a commit message explaining what the piece of work is.

But to be honest, my repo clone is sort of my own sandbox too, I don't consider Git a fully append-only log, so I'd sometimes do commit editing _on my local repo_. But once published, I consider it immutable.

(Or rather I'd prefer to; the team in the main project I'm working on right now has a rebase-heavy workflow.)

On a practical note, I'm fine with history cleanup done on the spot. E.g. I've committed three things in the past hour, I squash them together. Or I rearrange stuff I made over the course of the day. But I don't like attempts at messing with history that's many days old (or more), because at that point the person doing the cleanup doesn't have the context of the work in their minds anymore, so history edits throw away valuable information.

<comment><USER17> >> The way I view it, my editor is my sandbox

This position makes no sense to me. How can your editor be your sandbox but your branch before pushing is not? That's an arbitrary distinction without merit.

Noone rebases on a public branch so both scenarios are about what you do before publishing your work.

I think the whole conversation about history is missing the point. The problem we're trying to solve is complexity. Having a bunch of out of date commits floating about does nothing to reduce complexity.

</comment></comment></comment></comment></comment></comment><comment><USER18> boy, does this guy's ethos for fossil impress me a lot more than the justifications i hear for the insane complexity of git.

to me, this kind of result is the most compelling argument that the world of high tech isn't nearly so much a meritocracy as it is made out to be.

<comment><USER19> > boy, does this guy's ethos for fossil impress me a lot more than the > justifications i hear for the insane complexity of git.

git is not complex though. It just has an absolutely godawful "high-level" user interface.

Porcelain (high-level commands) are really shortcuts on _sets_ of low-level operations usually performed together, which is why e.g. `checkout` is used simultanously for reverting working copy chances and switching the entire thing to arbitrary commits or branches.

That also makes git extremely hard to learn "top down" beyond rote learning of a few commands: from that POV the CLI is completely incoherent so you can't really build an intuition for what command could do what operation. The terrible naming doesn't help either.

If you have the time and desire to start from the on-disk storage (ignoring packfiles) you can build your own in a few hours.

<comment><USER20> This is slowly improving, at least; `git switch` is now a thing, for example. [https://git-scm.com/docs/git-switch/2.23.0](https://git-scm.com/docs/git- switch/2.23.0)

<comment><USER21> At a glance, it seems to do the same as `git checkout` and `git checkout -b`. Can someone give a TLDR about the difference?

Edit: gonna be fun to see how guides like [https://www.atlassian.com/git/tutorials/using- branches/git-c...](https://www.atlassian.com/git/tutorials/using-branches/git- checkout) are becoming outdated in a way where switching/checking out doesn't mean the same thing anymore, but the article uses them interchangeably

<comment><USER19> These three invocations are not present in switch:

        git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>…
        git checkout [<tree-ish>] [--] <pathspec>…
        git checkout (-p|--patch) [<tree-ish>] [--] [<paths>… ]

That is, aside to / on top of the ability to switch to a specific branch or commit, checkout

* is used to revert working tree changes, possibly interactively

* is used to set working tree changes to either side of a merge (in case of conflict)

* is used to revert specific local paths to a historical version thereof, possibly interactively

</comment></comment></comment></comment></comment><comment><USER22> > The GitHub staff says that the four pillars of their organization are

> 1\. DevOps

> 2\. Security

> 3\. Collaboration

> 4\. Insights

Interesting to see _" Security"_ as number two.

</comment><comment><USER23> IDK who D. R. Hip thinks agrees that rebasing is bad, but I sure as heck don't.

Rebasing is good on private branches: it lets you write clean linear history. Conversely, intra-project-branch history is of little or no interest whatsoever once pushed upstream. Rebasing published branches is not a good thing, of course, but fans of rebasing don't propose that.

</comment><comment><USER24> Winners are not about who's best. Git is not better than hg, Koalas are not better than giant sloth, Windows is not better than linux. So? All major hosted scm dropped hg support. What op tries to do seems emphatically Quijote- ish

<comment><USER25> Isn't the English word Quixotic?

<comment><USER24> I don't know and welcome any correction to my grammar or spelling.</comment></comment></comment>


Innovation Haiku #1 - <AUTHOR>

"Starving or stoking, Scrounging or brandishing tools, How do you create?"<p>-Teresa Amabile and Steve Kramer <comment><USER2> My Creative Spark

Comes from keen observation,

and asking "How Come..."</comment>