Facebook first level interview for Linux admin position - <AUTHOR> http://bsdpunk.blogspot.com/2013/09/facebook-first-level-interview-for.html <comment><USER2> Dumb questions. Good sys admin interview questions shouldn't ask about specifics like "what is the command that does x" or anything that can be easily looked up in a manual. Rather they should quiz depth of knowledge of the Linux (if that's what its for) ecosystem.

I had some good questions posed to me during a Google DevOps interview, though I have trouble remembering what specifically they were about, I do remember that they were of a much more "holistic" and general bent. Instead of asking me to provide irrelevant details (i.e what are the switches for ls that list time oldest to newest) that are easily forgotten, they would pose a problem that seemed to have an easy and obvious solution and then make the problem more and more esoteric and difficult to solve.

These were the sysadmin trouble shooting problems and I found them quite interesting because they directly related to my experience and opinion that sysadmin trouble shooting is unfortunately sometimes quite complex and involves less an understanding of command syntax and more of a problem solving mindset.

Another point to take away is that if the interview is about linux, it should test fundamental linux things linux things such as testing the candidate's understanding of linux process management and signals. Perhaps filesystems as well.

My take away point is not that I think the FB interview was overly easy, but rather that it asks useless questions. This interview isn't looking for the sysadmin mindset at all.

<comment><USER3> This wasn't a FB interview - this was a phone screen before you got to the interview. Every linux sysadmin under the sun can answer 90% of those questions from "muscle memory." The purpose of this phone screen was to ensure that the incredibly expensive time of the interviewers was only used to meet potential candidates.

There are certain trivia or data that the entire community of linux sysadmins know, just by having worked with the operating system - and, if you miss more than about 20% of those questions - one can say with pretty much certainty that you are not a linux sysadmin.

I thought the questions were roughly the ones I would give to a technical recruiter to screen.

(PS: ls -lart - muscle memory, I type it 100+ times a day)

<comment><USER4>
      >(PS: ls -lart - muscle memory, I type it 100+ times a day)

_alias lsl= 'ls -lart'_

Place that in your .bashrc, or whichever shell you may be using.

Reduce typing.

<comment><USER5> Then you'll fail some silly interview question.

</comment></comment></comment></comment><comment><USER6> _6\. 3 Timestamps_ nix keeps on every file: created, modified, last access*

ctime is not when the file was created, it's when the inode (the file metadata) was last changed, as compared to the mtime which is when the file's data was last changed. Note that changing the file's data also updates the ctime.

<comment><USER7> Just to clarify things a bit more, I'll quote from the stat(2) man page [1]:

        time_t    st_atime;   /* time of last access */
        time_t    st_mtime;   /* time of last modification */
        time_t    st_ctime;   /* time of last status change */

        The field st_atime is changed by file accesses, for example, by
        execve(2), mknod(2), pipe(2), utime(2) and read(2) (of more than zero
        bytes).  Other routines, like mmap(2), may or may not update
        st_atime.

        The field st_mtime is changed by file modifications, for example, by
        mknod(2), truncate(2), utime(2) and write(2) (of more than zero
        bytes).  Moreover, st_mtime of a directory is changed by the creation
        or deletion of files in that directory.  The st_mtime field is not
        changed for changes in owner, group, hard link count, or mode.

        The field st_ctime is changed by writing or by setting inode
        information (i.e., owner, group, link count, mode, etc.).

[1]: [http://man7.org/linux/man- pages/man2/stat.2.html](http://man7.org/linux/man-pages/man2/stat.2.html)

<comment><USER8> Kudos on calling out the man page in the spirit of instruction.

</comment></comment></comment><comment><USER9> I guess Facebook employees don't have access to google and so this is why they want people to have this stuff memorized

;)

<comment><USER10> When you've been a sysadmin for long enough, you just know that stuff by heart. This is what they are looking for.

You don't have time to google anything when your system is down.

<comment><USER11> lies, lies, damn lies. you've never witnessed faster googling than when a system is down. googling is usually much faster than trying to recall the proper switches for all utilities. I find Google to be far better sometimes than even man pages. I've only been a sysadmin for 5 or so years so maybe my views will change

<comment><USER12> To me, it seems the questions were pretty basic and geared towards judging if someone has had experience actually administering linux servers. How many people (who actually competently deal with linux servers) need to use google to know what the output of top is? or how to kill a process? If you don't already know what MTU is about, how would you even consider an incorrect MTU as being an issue when you're debugging an issue in production?

Likewise, I wouldn't hire a Senior Javascript developer who can't describe in her own words what a closure is and what it's useful for, or talk about execution context (what 'this' refers to) and how to control that. You just can't have seriously written any javascript and not have encountered those things enough that they've been burned into your mind (though maybe an intern or a Junior developer that'd be okay)

</comment></comment></comment></comment><comment><USER13> Well, I have basically all of these correct... been doing this for very many years now so I'd hope so ;). I do hate these kind of interview questions (even first round interviews) though. They're not really useful at all in practice. It's like an old manager of mine said and I still think it's a good statement: There's knowledge you keep in your head and knowledge you keep on the web.

Essentially, more often than not if I'm doing something shell related I'll need to turn to man pages or doc files for a specific method/flag to use on a command unless it is the 'muscle memory' type commands like ls related flags, etc. There's only so much that is important to have memorized, and only so much you can memorize. The rest, look to the docs my friend!

</comment><comment><USER14> I hope that these questions were from the author's memory and not worded exactly as typed. Because the questions used for first round filtering of interview candidates should be clear cut and not open to interpretation.

Namely, question 14 is odd,

        What Signal does a child send to a parent when it is finished.

The child doesn't send signals in this event, the kernel sends signals to the parent when the child's state changes, and one of those states is the child exiting. Although, the default action of SIGCHLD is _ignore_ , and can a signal that is ignored be considered to be sent at all?

<comment><USER15> I'm sure if you just said SIGCHLD you demonstrated the knowledge they were looking for. If you gave your extended answer, they would probably be additionally impressed.

<comment><USER14> It really depends on who is administering the first pass questionnaire and how they have been prepared. When I was doing hiring, a dedicated recruiting team was tasked with doing this first round, which we called "prescreen questions". I spent a lot of time briefing the people talking to candidates for my team on how to interpret the answers, and I encouraged them to keep detailed notes so we could audit what candidates were saying and needed to adjust something. I personally reviewed every prescreen result to make sure we didn't pass on someone who could provide more than the straight forward answer. However, we found that prescreens were most effective when the answers were straight forward and there was only one way to interpret the question (that is, for prescreens, non-essay answers are preferred).

</comment></comment></comment><comment><USER16> fsck checks the consistency of the file system _and_ the kernel? Asking those two together seems really weird. If that's how it was presented the best guess I could make is sync (forces changed blocks to disk) and fsck.

<comment><USER17> My first guess was running package manager checksum verify, like "rpm -V kernel" , for rpm based distro. But i'm not sure if it was the question was aiming for.

<comment><USER18> The question, as written, has no answer. fsck only checks the filesystem. There is no way to check the consistency of the running kernel but a kernel panic is a telltale sign of INconsistency :)

<comment><USER19> What happens if you try to fsck /proc or /sys?

I presume 'not much' or 'you get an error', but I don't have an instance I'm prepared to sacrifice right now, just in case something hilariously destructive happens.

<comment><USER18> fsck doesn't run on a directory, it runs on a block device. You can't run it on /proc or /sys because those aren't backed by a block device. /proc only looks like it has a file system because the kernel "pulls" the "files" out of thin air when you try to access them.

</comment></comment></comment></comment></comment><comment><USER20> I'm not a sysadmin (though I run Linux and have worked in the Kernel) and I can answer 4 or 5 questions out of those.

So my question is, is this all you need to be accepted at Facebook? or "First level interview" means more difficult stuff comes after this?

<comment><USER21> There's more to come. I've interviewed with Facebook for a similar position.

After a phone screen, they setup another call that was probably more intense. They asked me to be near a computer with a net connection so I assumed I'd be writing code or troubleshooting something.

I ended up turning it down because I received an offer from another .com that seemed more promising but I believe if I passed the next call, I would have been flown in.

<comment><USER20> Oh I see, so probably just an interview to filter out candidates.

<comment><USER22> This is standard issue phone screen sort of stuff. You could have a technical recruiter do this, which is what I would assume happened here.

</comment></comment></comment></comment><comment><USER23> The last question isn't answerable; it's kind of like the question "have you stopped beating your wife?", the question presupposes a fallacy.

Actually a child almost never sends a signal to the parent process on termination; the signal is sent by the kernel from the kernel context.

A child could manually send a SGIC(H)LD by using signal(2), but then any wait(2) would block; this is why you should always use a non-blocking flag to waitpid(2) or its ilk in case some idiot program sends your program a SIGC(H)LD.

</comment><comment><USER24> suddenly i completely understand why you weren't invited back...

i'm taking the fact that this article is on the front page of HN as my sign that i've outgrown HN.

<comment><USER25> What better places have you outgrown to?

</comment></comment><comment><USER26> That's a good first level interview I guess. I'm a .NET programmer and I knew all but one (but I am also a full stack dev, so it's probably normal that I would know these things.)

<comment><USER27> I guess it depends on the stack. I'm also a .NET full stack dev, but my stack includes Windows servers instead of Linux servers.

It's been 5 or 6 years since I've done Linux sysadmin work, but I still knew a bunch of these.

</comment></comment><comment><USER28> Didn't they ask you to sign a non-disclosure agreement at these kinds of interviews?

</comment><comment><USER29> ridiculously easy, and I'm probably the least experienced Linux person on HN.

<comment><USER30> Presumably they are screening for competence. They don't need Doug McIlroy to run their servers.

</comment></comment><comment><USER31> Good illustration of why in some ways it's actually easier to be a solo founder of a startup than an employee of one!

I know next to nothing about Linux -- it's yet another multi-user, demand paged, virtual memory operating system with an 'embedded' operating system and a hierarchical file system, written mostly in C. Right? That's about all or a little more than I know about it. There have been a lot of those, back to Multics. So, Linux is yet another one. Okay.

But I'm developing on Windows. Even on Windows I don't know that much detail. For such questions on Windows, I wouldn't know a good source (wish I did), and when I need answers to such questions have to Google/Bing a lot, hit Stack Overflow, etc., one silly little question at a time. Bummer, but the frequency with which I have to do such scavenger hunting in muddy swamps has been declining.

No doubt when I bring up Windows Server I'll have a lot more such detailed mud wrestling to do; similarly for serious work with SQL Server. Bummer -- again I'll be screaming at the lack of good documentation for such questions.

Still, so far my software development is going ahead well without such detailed knowledge. Actually I've long suspected that once my company gets serious with number of users arriving per hour and revenue getting up to the useful level, I'll get answers to such questions by calling for paid, expert support at Microsoft. It's their software, not mine! And while most such questions are simple conceptually, digging out the answers often is not.

Indeed, one reason I selected Windows instead of Linux is the hope, maybe false, that one way and another, say, from Microsoft or Stack Overflow, books, Microsoft's MSDN Web site and the similar site for SQL Server, I'll have better means of answers to such questions. Similarly, when I need a high end LAN switch, I'll try to pick Cisco heavily due to a hope for good sources, possibly from Cisco, for answers to such questions. LAN switching is their darned business, not mine; they can do their business, and I'll be a paying customer, and I'll do my business.

For hiring, there's a recent remark from Richard Branson that he hires for personality and not skills since skills can be taught, he believes quickly, while, implicitly, it appeared he was saying that personality could not be taught quickly. Actually, for such detailed questions for Linux/Windows Server, he is significantly correct. So, I'm hoping to hire bright people with good personalities who are at least okay computer users (even if they have never written a line of code in their lives) but are good at typing, reading, writing, speaking, 'critical thinking', getting some okay understanding from some horribly badly written material (i.e., nearly all computer industry documentation), and analyzing ambiguous situations. Right: Sounds like I might want to hire some good humanities majors! Nerd me!

Then have such employees start with simple things, say, plugging together a server, working up a simple, quick and dirty parts inventory system (maybe just a flat file with some keywords maintained with just a text editor maybe with a few macros -- maybe even a, yuck, spreadsheet), pulling CAT 5 cables and using a crimping tool for the ends, installing Windows Server, calling Microsoft for technical details, documenting what they learned about how to install, configure, and administer Windows Server, etc.

Then, teach them programming a few lines at a time, e.g., Visual Basic .NET (apparently about the same as C# for getting to the CLR and .NET Framework but, to my eyes, easier to read on the page than C# with its syntax from C and, thus, deliberately _idiosyncratic_ ).

For basic computer and network architecture, I'll give them a 30 minute overview lecture they can capture on video and use for other new hires. The hope is that such people will be able to grow in 'skills' as fast as the company grows. I.e., I'll show them what I already know, and as we need to learn new things it's their job to dig them out and document them for others. Did I mention I want them to know how to write (and _not_ learned in the computer industry)?

Then for Facebook hiring, I would ask: Whatever the heck happened to the last person in that position? And, why the heck does Facebook have to go recruiting for such a person? You mean, Facebook doesn't have a backup for such a person? Or, Facebook has 400 billion executing instances of Linux, may be compiling some unique versions of Linux, and, still, has only one Linux system administrator? Not good.

Broadly, if Facebook needs such 'skills', then they should grow the capabilities internally. Or, I can do my startup _without_ knowing all that stuff; if Facebook would want me to know that stuff, then they should pay me to learn it.

This stuff about having to walk in with a lot of detailed knowledge, learned on my dime and time, just as needed by Facebook for just an 'employee' position in a big company, that is, an organization that in a few years might just decide to layoff 20,000 employees, is getting to be a bad, old story. A startup, even for grass mowing, literally, looks more promising.

<comment><USER32> "This stuff about having to walk in with a lot of detailed knowledge, learned on my dime and time, just as needed by Facebook for just an 'employee' position in a big company, that is, an organization that in a few years might just decide to layoff 20,000 employees, is getting to be a bad, old story. A startup, even for grass mowing, literally, looks more promising."

Spot on! Another way of looking at it is that tech companies don't want to spend $ training their employees (including a slightly longer ramp up time for an employee to begin contributing). If they did, the hiring process would be: you had a 4.0 in college. This shows you are good at learning new things. Lets check for personality fit and some other things that a college transcript does not capture. Do a one hour interview. Hire or No Hire based on this.

As a startup founder, you should be happy about this state of affairs. The attitude of large companies makes it easier for you to hire :)

<comment><USER31> I'm getting happy: I'm 70 miles north of Wall Street and that means really close to Vassar and not far from Princeton, Yale, Harvard, and more. So find some bright, humanities major coeds who otherwise would have to start in retail or go to law school or for an MBA and get them started.

So, they have great SAT scores, know how to study and learn, know what high quality work is, are good at working with people, are really good at _reading comprehension_ , can knock out an A+/A+ term paper between 10 PM and 7 AM with just a quart of coffee, can give a good presentation, etc.

So, teach them about Volts, Amps, Watts, Ohm's law, DC, AC, resistors, capacitors, inductors, basic electronic signals, the basic conceptual principles of how a processor core works, a little on caching and main memory, data representation 101, how a disk drive works, the basics of an NIC, Ethernet, a LAN switch, and TCP/IP, and IP router, a little on memory protection, an 'embedded' operating system, virtual memory, virtual machines, a file system with locking and security, console sessions and command lines, text files and a good text editor, the Internet from DNS, SMTP, POP3, to base 64, MIME, HTTP, HTML, and CSS, the basics of programming languages, e.g., Visual Basic .NET and its memory management, classes and instances, the .NET Framework, relational database, SQL, SQL Server, how to use Microsoft's MSDN, about Stack Overflow, HN, and how to Google/Bing to get answers to questions, how to use our technical support account at Microsoft and Cisco, all in about one afternoon, with some exercises, and then have a graduation party.

Then get to work on some basic stuff, say, plugging together another 20 servers, repairing a server with a busted hard disk, etc.

Clean, indoor work, no heavy lifting, and better than grass mowing or retailing.

</comment></comment></comment><comment><USER33> It's rude to post their questions online.

How is this lost on people??

<comment><USER34> While I don't really have a problem with being "rude" to a corporation, especially some evil behemoth like Facebook, it's worth noting that sharing these questions probably violates an NDA that was signed/agreed to before the interview.

<comment><USER35> I hope they don't waste everyone's time with having an NDA signed before the _first_ round of interviews? What would it accomplish?

<comment><USER36> Its main effect would be to filter out people who aren't desperate.</comment></comment></comment></comment>


Pump manufacturer programs their devices to fail prematurely and lowers price - <AUTHOR> http://www.xavitech.com/setting-prices-suit-service-life-want-pumps/ <comment><USER2> What's fascinating is that they're being upfront with their customers about this, rather than trying to sneak it in. They're also explicitly letting their customers decide how long the pumps should last, and pricing accordingly.

I wonder if other existing DRM-like mechanisms for hardware would be better received if their manufacturers took this strategy.

</comment><comment><USER3> Selling exactly the same hardware with different prices and performance is actually a pretty old practice. I've read stories of people long ago buying hardware upgrades for IBM mainframes and being surprised when the IBM engineer just came over and cut a wire on the backplane. "OK, you have twice as much memory now. Have a nice day!"

<comment><USER4> A pal of mine told me about a make of car (could've been the Fiat 128 or the VW Polo - circa mid to late 80's) that had a small analogue clock as an optional extra.

Apparently it was always factory fitted into the dashboard. If you didn't order the clock, or whatever option pack that included the clock, the manufacturer just put a blanking plate over the clock face and (I think) disconnected the power (my memory is vague on this). He claimed to have discovered this on one of his, or his mother's cars, when curiosity got the better of him as to what was behind one of these accessory blanking plates.

This may have been a shaggy dog story though.

<comment><USER5> I have a Mazda 3, which didn't have the fuel computer display (shows you remaining mileage, current mpg etc). After I bought it I found out that by doing a little dance with the buttons and turning it on and off I could enable it. Now the only difference is that mine has a blank button to cycle through it rather than one that says "Fuel Comp".

</comment></comment></comment><comment><USER6> I'm not quite sure how I feel about this. Mechanical equipment lifespan normally follows a well curve. Premature failures from manufacturing defects and improper component installation or commissioning taper off to a period where there is relatively low failure rates with proper maintenance until a certain point where equipment fails from age (fatigue, worn parts etc). If the end user is the one to specify the component, this could be great, you're not paying for unused time at the end of the components life. Some components are going to be replaced on a time schedule regardless of if there is usable life in it or not, some things are better to do on your schedule than a broken components. There is a warranty on the component for the full life of the pump so if you're doing the spacing you can be reasonably assured it will last its required life span or replaced. On the other hand, if I purchase a piece of equipment from a different company and expect it to last N years, but they are using this component to save money and only opt for it to last M years, and don't disclose the life span, I could end up paying for N-M years of expected service that I don't get to use. As an aside of other software limited hardware, Caterpillar c-series Diesel engines are software limited to a certain extent. If you need more horsepower call the service tech and they can increase the HP. Disclaimer: I heard this from another marine engineer so don't know if they need to upgrade other components as well or if it's completely a software de-rating.

</comment><comment><USER7> Sounds like a market for an aftermarket service company to reprogram the pumps not to break!

<comment><USER8> it'll take 15 minutes for someone to figure this out. then we'll have 0 day warez for pumps.

</comment></comment><comment><USER9> This would logically mean they can make their pumps really cheaply and long- lasting, or they wouldn't have the markup to be able to do this. I'm not sure how I feel about their position, but I know I'm less comfortable about how this feels like "licensing" a product than I am about the markup they're admitting to making in the first place.

</comment><comment><USER10> Synthetic, premature obsoleteness for pure economic gain is an engineering insult & represents environmental malice.

<comment><USER11> How do you know this wasn't requested by their customers?

<comment><USER12> That's irrelevant to the point about environmental malice.

The pumps provide a value, which you are pointing out the manufacturer can capture more of by offering artificially limited pumps at lower prices.

GP poster is pointing out that the pumps have a cost to the environment and that the artificially limited pumps provide less offsetting value for this imposed cost.

</comment></comment></comment><comment><USER13> So they are basically renting their pumps? When the pumps fail, they must get them back and resell them to another customer. Else the economics would not make sense. Unless they send less to build a shorter life pump, but my impression was no, they program it to fail after a certain number of operating hours.

<comment><USER14> The economics make perfect sense. Imagine you have a pump that lasts 1,000 hours, and it costs $10 to build. You have a reputation for making great pumps.

To recoup your R&D costs and make a profit, you decide that you're going to sell these pumps for $100. Those in the market for a 1,000 hour pump think that's a fair price, but those who only need a 100 hour pump think that that's outrageously expensive.

If you bring the price down to make the 100 hour pump people happy, you're cutting into your margins for the 1,000 hour people. So you segment your market: $100 for a 1,000 hour pump, $40 for a 100 hour pump. Your 1,000 customers continue buying the pump at the price they've always been paying, and some of the 100 hour people start buying at $40. That incremental revenue is all gravy; you didn't have to sink R&D money into a second product (other than building the DRM)

<comment><USER13> thanks. yes you are right. it is market segmentation. you move more units for a lower weighted average margin. just seems silly your actually modify the product to make it fail early just because someone paid less for it. i get it for software, you leave features off or put them on and charge less or more. but for an actual physical product, you are playing with operating hours as a feature, just seems new to me. if i was to do it, i would put some money into picking cheaper parts for the lower lifetime pump. then i could perhaps build it for $7 and get more margin for these sales. but i guess it depends on how much money you put into integrating cheaper parts. but even making it fail early by programming cost some money.

<comment><USER14> I agree, it's totally weird. I've been thinking about it ever since I saw the article, and thinking about other pieces of equipment that I have that operate on a similar model.

I've got an oscilloscope that I bought as a 50MHz model, knowing that an upgrade to 100MHz could be purchased after the fact. When I bought it, I didn't need the extra bandwidth and it was a decent price. Recently, I started to need the extra bandwidth so I inquired about the upgrade cost. $300. To do the upgrade, they give you a file that you stick on a USB key.

Part of me is grumpy about the fact that the equipment I bought was actually capable of 100MHz out of the box and was just software locked. And part of me is happy that I got to hold on to my extra $300 until I had a compelling reason (read: a client was paying) to do the upgrade.

$X was a decent price for a 50MHz scope, and $X + $300 is a decent price for a 100MHz scope.

</comment></comment></comment></comment><comment><USER15> Bought a dot-matrix printer years ag, the cheap one, without double-wide character support nor lower-case (just the capital letters). It arrived. Inside was a jumper block. Reversed it - now it had all the features!

</comment><comment><USER11> Interesting how a lot of comments here attribute some inherent evilness to the manufacturer, when more likely it's customer-driven feature that they've been asking for or their sales staff saw the need for. If customers don't want or need it, it won't be profitable. So you have nothing to worry about.

</comment><comment><USER16> Lovely. So now software defects can _directly_ affect product lifetime. Just the thing I need for something that has to live in the field for 15 years.

Well at least I know one more company whose products I should avoid.

<comment><USER17> Or patron them, and sell a mod to override their premature obsolescence.

</comment></comment><comment><USER18> This kind of offends us as technologists, but it may be the wave of the future. I think business would generally prefer to buy a "defined benefit" rather than gamble on the longevity of a device.</comment>


Ask HN: Users vs. Time with Emotional Annotations By PG - anyone have it? - <AUTHOR>

Anyone have a link to the graph annotating "founder emotion" on a time v users in a startup?
I think it was drawn on whiteboard and someone snapped a pic of it at a YC dinner?
I remember it having a "trough of despair" :)
Would love to see it again - thanks! <comment><USER2> <http://dl.getdropbox.com/u/1704650/index.html>

<comment><AUTHOR> Thanks! :)</comment></comment>


Autistic people can hear more than most, which can be a strength and a challenge - <AUTHOR> https://theconversation.com/autistic-people-can-hear-more-than-most-which-can-be-a-strength-and-a-challenge-77039 <comment><USER2> And depending on the person can smell more and/or taste more and/or touch more and/or probably see more, and because of this sensory overload more.

</comment><comment><USER3> I don't know much about autism, but as someone who was recently diagnosed with ADHD in his late 20s and recently going in medication, I've noticed that I'm less bothered by sounds and smells than usual. Does autism have any relation to ADHD?

<comment><USER4> They are frequently comorbid and have large symptomatic overlaps, and genetic studies hint at a shared cause, but beyond that little is certain about their relationship. The mainstream view does not currently regard them as the same disease, although it has been proposed.

Sensory sensitivity issues in autistic-spectrum disorders are common (and can go either way, i.e. over- and under-sensitive).</comment></comment>


JavaScript makes relative times compatible with caching - <AUTHOR> http://www.37signals.com/svn/posts/1557-javascript-makes-relative-times-compatible-with-caching <comment><USER2> Seen this used a few times before, but not usually with ugly custom attributes and innerHTML :/

Those 2 things really have no place anywhere IMHO.

<comment><USER3> Agreed, I'm surprised they decided to use a non-standard attribute. But it is a simple and elegant technique if you want to save the server from doing extra work it doesn't need to.

<comment><USER2> Sure, but it's just as easy for the server to output a javascript structure with the data in really. eg

Using the DOM to store program data just doesn't seem nice to me.

<comment><USER4> >> Using the DOM to store program data just doesn't seem nice to me.

I disagree. I think the DOM is where data should be (look at meta tags, for example). Storing data in json style or xml-like attributes sound a bit like repurposing things.

Also, according to Steve Sounders, sprinkling script tags everywhere (which I suppose is the easiest way to get the json approach working in a site of arbitrary complexity) is not a good idea in terms of loading speed.

<comment><USER2> What if your data contains html entities, newlines, unicode etc etc etc. HTML is a hornets nest, whilst js is pretty sane. I would never advocate sprinkling script tags everywhere :/ 1 is enough usually. (I would obviously in this case, have 1 script tag at the end of the body, with the data structure, and the function to initialize the span tags).

<comment><USER4> As far as encoding goes, my experience has actually been worse on the javascript side, specifically with french text and regular expressions buried in 3rd party libraries. Compared to that, grabbing data from the DOM using DOM text node methods is a walk in the park.

The thing with the json solution is that once we have things being ajaxed in, it becomes very hard to maintain the code. Has id="date7" been used? What if I add a comment while the "shoutbox" feature is updating?

Having the data in HTML would let us use something like Jquery's livequery and it would work regardless of how the data and how much data got into the page (plus we get the benefit of the no-javascript scenario I mentioned before).

<comment><USER2> json? ajax?

The solution I posed was a simple inline javascript at the end of the html. The js data is generated at the same time as the html output. The IDs all match, and are used once.

I've never seen any issues with encoding in js, so I'm not sure what you mean about french text, regexps...

<comment><USER4> What I'm saying is that once a site becomes more complicated (e.g. if the data comes after page load, in an ajaxed popup, for example), that simple solution becomes harder to maintain (or to implement without wasting bandwidth). To be fair, if you don't work on complex web apps, you'll probably never run into this.

>> I've never seen any issues with encoding in js, so I'm not sure what you mean about french text, regexps...

Good for you. I hope you never see these types of bugs, they are nasty to troubleshoot.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> How far can we generalize this? If an application has millions of users, can just a little of your server-side load into their browsers can end up saving real money in server/scaling costs?

More evil-ly, how much computation/storage capacity could Google get by pushing off work/safety advantage of GMail users' machines? Of course, a single computer isn't reliable, but with millions of users, it's a simple matter of failure/redundancy probability. A distributed file system in browers' Gears databases would work just like GFS, but with higher failure rates.

<comment><USER6> To address your first point, GitHub are already doing some of this: they reduced server loads by lazy-loading commit data when cached data isn't available.

<http://github.com/blog/293-while-you-were-sleeping>

At work we do a fair amount of client-side form validation. While we have server-side validation too, doing it in the browser as well vastly reduces the number of times invalid inputs make it through to the server and have to be expensively processed. Of course, this creates other problems (making sure the client- and server-side validation routines precisely mirror one another, for example), but for some use-cases it's worth it.</comment></comment>


Why didn't France adopt the longbow like England did? - <AUTHOR> http://www.peterleeson.com/Longbow.pdf <comment><USER4> Interesting. Although this point of view might be a bit simplified, there's another example of a weapon, which was both relatively cheap to make - <USER2> really hard to use unless the whole society was built around the skills required to use it.

Mongols! Light cavalry using composite bows was both unbelievably effective and hard to copy for everybody but steppe nomads. All Mongols were hunters, they practically lived with their bows on their horses. So the whole population could do warfare.

While back in the days, in both Eastern and Western Europe, contemporary warfare was rotating around heavy cavalry, and one can't have too many knights. Even if somebody managed to gather an army more or less comparable to Mongol hordes - heavier cavalry would just be meat for lighter riders making circles around them.

Besides, feudal lands never managed to be centralized enough to counter mongols. In medieval Rus' the need to centralize led to the rise of Moscow - and it took quite a while anyway.

<comment><USER5> It's hard to compare Mongols to Europeans. The composite bows rely on animal- based adhesives, which are great in cold and dry climates, but fall apart in humid and warmer climates.

Also, light cavalry armies are useless against castles and fortified cities as the ones found in most of Europe, specially when you don't have huge, flat battlefields that allow light cavalry to circle any target.

In other words, Mongol warfare was perfect for the environment they were created for: vast empty dry lands with few geographical features and settlements which are far from each other.

<comment><USER6> Re: "light cavalry armies are useless against castles and fortified cities as the ones found in most of Europe"

Not true, as the Chinese cities at the time were much more fortified than Europe. The Mongols were able to plunder the surrounding lands.

Also, despite Europe's fortifications, a scouting party led by Subutai of 20,000 horse archers, widely wiped out a much more significant force of Central Europe soldiers, greatly outnumbering the Mongols. Fortified cities may cause trouble, but by this time, Mongol dominance had incorporated Chinese siege technology that fortified central european cities had not seen.

<comment><USER7> I read a long discussion about this on Quora. What I could gather from that was there were far more castles in Europe than China. Also Europe has too little plains to be able to support a mongol army very long. They each had something like 5 horses. There isn't enough grass for a large mongol army like that. One the debaters claimed e.g. that European castles were very well supplied for long sieges and would run out of food much later than an occupying mongol force which would be vulnerable to counter attacks.

European heavy cavalry was not useless against mongols. It is just that they were seldom effective when mongols could just run away from the battle field. Easy to do when they were much lighter armoured. But if Mongols maintained a siege they had to stay in position which would have made them vulnerable to European nights which were probably superior to mongol soldiers if they could not perform hit and run tactics.

Apparently the mongols beat the Hungarians initially but when they came back and the Hungarians had built lots of castles, they were soundly beaten. The sieges dragged on and they would get harassed by Hungarian forces which could always retreat back to castles while mongols starved.

My understanding is that the Mongols managed to conquer the more hilly southern China by using conscripted Chinese soldiers. So they were not really using standard Mongolian tactics there. Duplicating this in Europe would have been difficult because unlike China Europe did not have the same kind of central government which would have allow the conquest of a few cities to gain huge tracts of land and extra manpower. They would have had to conquer huge numbers of castles which would have dragged out in time.

In fact Machiavelli talks about this in the Prince. The Ottomans, Roman Empire, China etc were far more centrally controlled which made them one strong unit but once you conquered the central city of government you would control the whole country. The Feudalistic European countries however might not as easily marshal huge combined forces but they were extremely difficult to conquer because you had to conquer every little vassal state one by one. Considering that every one had a castle this was no easy task.

One should not completely discount the effectiveness of European military. During the crusades, the muslim forces would usually use Mongol like tactics to wear them out. But whenever the crusaders managed to corner a muslim army they crushed it with their heavily armoured knights.

<comment><USER8> 5 horses is quite a bit of food to feed the army... the more the army eats the more grass you have left for the horses... so when the castle is running out of food you have 1 good well fed horse and 1 good well fed soldier who has to win or he doesnt have enough horses to go home

i think that wins

<comment><USER9> That's fine for the first siege (assuming an extra couple months was all you needed), but now you have to supply up with 4x(number of horsemen) for the next one to be in the same position. Tens of thousands of horses for even a smallish Mongol army. And at least some of them must be trained for war, specifically in the Mongol fashion, not just any ol' training. In short, it's not gonna happen on any reasonable time scale.

Plus you lose whatever advantage the extra horses gave you until you get more—I mean, I'm sure they didn't keep them around just for fun. Greater travel speed by resting them off, extra cargo/loot capacity, whatever their reasons were.

</comment></comment></comment></comment></comment></comment><comment><USER10> tl;dr:

The abstract does a wonderful job. It is will worth reading.

Longbow was cheap and technically superior, but required training. Crossbow more expensive, required less training. Rulers of England less worried about rebellion, OK to invest in training. Rulers of France/Scotland not so happy because of fear to give potential of overthrow to the people (Scotland not in title, but in article along with France).

Perhaps an analogy could be painted with companies today. Those that churn, and those that nurture skills.

<comment><USER11> If I remember correctly (and I'm still looking for a better source than this[1]), the Duke Of Wellington had requested a corps of longbowmen be made ready for use against the French in the Napoleonic wars, but was advised that no one with the skill needed to train them still existed (the training being the most difficult part of the technology). The last use of trained english longbowmen seemed to have been by some of the royalists during the English Civil War, and after the parliamentary victory practical knowledge of longbow archery as a military arm had been lost without anyone really noticing.

It's hard for me to imagine a pivotal art or technology being lost like that, but I'm willing to bet its not at all uncommon if we look across history. For another military technology example, the art of dogfighting was deemed to have been lost for a brief period between WWII and the air war over Vietnam, and had to be re-engineered.

[1] [http://everything.explained.today/English_longbow/](http://everything.explained.today/English_longbow/)

<comment><USER7> Actually one of the points made in the book Guns, Germs and Steel is that technology and inventions aren't developed because there is a need for them. Rather inventions pop up and disappear all the time through history in different cultures. But what makes the technology stay around is that it ends up getting used.

E.g. South America did invent wheels, but since there was no ox or horse to pull the invention had not real practical application beyond toys and never got developed.

So according to this view I guess technology is always in danger of disappearing if it isn't being used.

E.g. the Apollo moon rocket can't be build anymore because the engineers, companies and machines needed to build all the parts and assembly it are no longer around. One would have to recreate a 1960s American industrial base to do it.

<comment><USER12> Surely Llamas could have pulled some cargo. This says that an adult llama can pull cart loads of up to 200lbs: [http://workingllamas.com/?id=93](http://workingllamas.com/?id=93)

That's significantly less than a draft horse, but probably roughly the same as a pony.

<comment><USER13> Actually, the issue there is terrain. Llamas are very agile and can carry loads to areas that neither horses nor carts can reach. Smaller loads, of course, but still much more than a person can carry.

Even today, horses aren't really a thing in the Andes, compared to say, Patagonia.

</comment></comment></comment></comment></comment><comment><USER14> Kevin Hicks is a great resource on the longbow: [https://www.youtube.com/watch?v=EvKJcxa8x_g](https://www.youtube.com/watch?v=EvKJcxa8x_g)

He is also very knowledgeable about all things from this period of history: [https://www.youtube.com/watch?v=hUYd6pNy6QU](https://www.youtube.com/watch?v=hUYd6pNy6QU)

There is also some more detail regarding the make up of the "English" army bowmen here: [http://www.bowyers.com/bowyery_longbowOrigins.php](http://www.bowyers.com/bowyery_longbowOrigins.php)

Sidenote:

\- Bowyer: Makes the bow

\- Fletcher: Makes the arrow

\- Stringfellow: Makes the string

\- Arrowsmith: Makes the arrowhead

<comment><USER15> Sounds like somebody figured out the single responsibility principle

<comment><USER16> See [http://www.adamsmith.org/adam-smith- quotes/](http://www.adamsmith.org/adam-smith-quotes/)

</comment></comment></comment><comment><USER17> This seems a good place to post about Mad Jack Churchill, who brought his longbow to France in 1940 and shot a German with it: [https://en.wikipedia.org/wiki/Jack_Churchill](https://en.wikipedia.org/wiki/Jack_Churchill)

<comment><USER18> Thanks for posting this!

my favorite bit:

"He startled train conductors and passengers by throwing his briefcase out of the train window each day on the ride home. He later explained that he was tossing his case into his own back garden so he would not have to carry it from the station"

</comment></comment><comment><USER19> I see a possible problem with this theory: in few words, according to the authors the French and Scots did not adopt the longbow for fear of rebellion. Still the nobles participated to the very battles that saw them being defeated by the English and their longbow. If the longbow was cheap and relatively easy to adopt, a noble aspiring to the crown would have been able to develop the technology independently from the (unstable) central government and have an even easier road to glory against their own technologically inferior king.

I admittedly did not read carefully the whole paper, but this possibility does not seem to be addressed.

<comment><USER20> There's another major problem: preventing peasants from being a threat whilst still yielding some benefit from the longbow could easily have been achieved by restricting archery training to nobles and selected privileged guards, who had more time and inclination towards military training than the peasantry anyway. This would have resulted in less firepower than the English mass armies, but far more than the crossbows they used instead (indeed, since the principal advantage of the longbow over the crossbow was rate of fire, it would have been even more important to take advantage of in an army with a relative shortage of archers)

Alternate hypothesis: the French lacked the experience of the English/Welsh in making longbows and training people to use them, so struggled to see any evidence of superiority when experimenting with longbows over the crossbow technology they were more familiar with. A local maximum.

And the posited relationship between (in)stability and training regimes for the wider population looks more plausible flipped on its head: the less stable English kings paid less attention to the promotion of archery than Edward III not because they hoped laxity in training would result in any peasant armies raised against them being worse shots, but simply because they had more important things to worry about than archers.

<comment><USER21> >There's another major problem: preventing peasants from being a threat whilst still yielding some benefit from the longbow could easily have been achieved by restricting archery training to nobles and selected privileged guards, who had more time and inclination towards military training than the peasantry anyway.

That was pretty small number of people in the middle ages, and they would already have been trained as mounted knights or men-at-arms so retraining them as archers would not be a net gain unless one archer was more valuable than one man-at-arms which I don't think is likely.

The advantage of the longbow is that once trained, you could raise a large army quite cheaply but that army only worked as part of a combined arms operation that also had armoured infantry and cavalry. That means that you don't want to sacrifice the other elements of your army in order to build a longbow capability.

<comment><USER22> There's also the whole concept of feudalism to throw into the mix. Longbows were cheap so you could require your peasantry to own and practice them - <USER3> at least for a community to supply X archers per Y population.

Knights are significantly more expensive, and again require years of practice. The principle of feudalism was landholding being tied to military service - you hold the land from your feudal lord and in return this supports your ability to provide military arms.

Take away the requirement for you to provide expensive armour and destriers (the war horses knights rode) and you remove the need for you to hold land, which undermines the political settlement of the Kingdom.

</comment></comment></comment></comment><comment><USER23> I still remember being blown away when I realised how institutionally organised longbow practice was as I read this Rosemary Sutcliff as a child

[https://www.goodreads.com/book/show/1195105.The_Armourer_s_H...](https://www.goodreads.com/book/show/1195105.The_Armourer_s_House)

</comment><comment><USER24> The intro still assumes that the battles won by the English in the Hundred Years War were due the longbow (alone), which AFAIK is quite debatable (at least outside of England, where Agincourt is a bit of a national myth, even more than e.g. the Black Legend).

And never mind instability, the French also weren't as geographically isolated as the English and thus it was easier to hire mercenaries. Genoese crossbowman being a particular example.

The penetrative ability of the longbow is also greatly exaggerated, citing a book that did some pretty shoddy testing (flat sheets of poor quality metal used as targets, but hardened bodkins as penetrators, 10m distance, no padding).

<comment><USER25> France won the Hundred Years War.

<comment><USER24> My bad, of course I meant the famous English victories, changed the post to reflect that.

</comment></comment></comment><comment><USER26> I think that the way this paper discusses on the longbow as being the superior weapon may obscure a key fact here. Man for man, a crossbow is a superior weapon; requires less skill to operate, has longer range, much easier to aim, better penetrating power. The main advantage of a longbow is how simple and cheap it is.

Speed of reloading is another advantage the longbow has, but I think this article overstates it. While some crossbows do require using a stirrup or crank to load them, there are others that you can reload against your hips, and shoot from there, to increase your speed considerably, at some cost to accuracy. I know people who have managed to get 6 bullseyes at 20 yards on a crossbow in 30 seconds. Meanwhile, archers would not be firing at the maximum possible rate in battle; ammunition is a limited resource, and with the draw weights of warbows fatigue would set in quickly. Overall, with the archers they had and bows they had at the time, it is likely that the longbows were able to be a little faster than the crossbows, but it's not a night and day thing; and the range, accuracy, and penetrating power on the crossbows were better.

The simplicity became an advantage in a few battles, which came after substantial rainstorms that caused problems with crossbows more complicated mechanisms. But the main advantage was how cheap and fast to produce they were; you could easily arm a large populace quite quickly. In order to take advantage of the longbow, you had to do that; you needed a very large number of archers to effectively take advantage of longbows, while you needed fewer archers to be effective with crossbows. But because it was cheap and simple, it was feasible to do that.

I think that cost and simplicity of the longbows were their biggest advantage; speed perhaps a secondary factor, but the sheer numbers were likely to be more important.

There is, of course, an interesting parallel here with some trends in modern military spending. The Joint Strike Fighter is a technological marvel; one of the most advanced pieces of military equipment ever. However, they are staggeringly expensive, and not actually the best dogfighters in the sky. You wonder how much more effective spending that money on more and simpler weaponry might have been.

<comment><USER27> You are directly contradicting a researched paper that explicitly contradicts everything you just said. Why do you think you're right?

Read page mid-page 691-693.

I'm also not sure what the point is of you talking about today's modern crossbows which are unsurprisingly easier to reload.

<comment><USER26> First, this research paper is about a game theory analysis about a political situation that may have made the French and Scots leery of being vulnerable to usurpation by arming a large population. The material on pages 691-693 is all background material, not the actual research material of this paper.

I did read 691-693. I am not contradicting any of the information in it; merely saying that I think they are overstating the direct superiority of the longbow. Strategically and tactically, it's clear that arming a large number of archers and using them in the early battle is superior, and the cost and simplicity of the longbow makes that much easier; but it's not because a single longbow is better than a single crossbow. I think that the longbow was a superior weapon, in the sense that the armies that adopted the longbow strategy clearly beat those that relied on crossbows, but I think that the way that the paper couches its introduction makes it sound like, side by side, a longbow was a superior weapon to a crossbow.

I'm not talking about modern crossbows, I'm talking about reproduction medieval crossbows. I do medieval recreation as a hobby, I shoot longbow, I know people who shoot crossbow. The longbow is faster, though as I mention, I know people who can reload and shoot from the hip and get 6 accurate shots off in 30 seconds. And the crossbow is more accurate, gets better range, delivers more power, and is easier to shoot.

Now, I don't shoot a 160 pound warbow, I don't have the strength for it. If I did, I would get some more power and range out of it, at the expense of accuracy and speed, as I would fatigue much more quickly. With a crossbow, you can use both arms and brace against your hip to draw, so even without any stirrup or crank, you can shoot a much heavier crossbow than you could a longbow. That extra power means more penetrating power and a flatter quicker flight (or more range if you increase your angle), and the fact that your muscles are not straining to hold the bow drawn means you can aim more accurately.

</comment></comment></comment><comment><USER28> I wonder if this practice of arming citizens with easily procured long- distance weaponry that in a less stable country would be feared to become useful in a rebellion also could be considered one of the memetic ancestors of modern American firearm culture.

</comment><comment><USER29> I don't know, maybe because bow is a peasants' weapon, and France had _knigts_?

Western Europe had its share of stupidity, like kings leading charges instead of commanding battles on a tactical level.

<comment><USER30> > _stupidity, like kings leading charges instead of commanding battles on a > tactical level._

Why exchange one form of stupidity for another? If you're going to ping medieval Europe for military stupidity, then instead suggest that the people commanding the battles should be trained military specialists, as they are today. There's nothing magical about kings that make them better at battle tactics.

<comment><USER29> The problem with kings leading charges is that there's nobody to command the battlefield, not that they were skilled or not. Eastern Europe had that much better.

</comment></comment></comment><comment><USER31> Ah, Agincourt-fetish, one of the few fetishes you can display in public without looking too ridiculous (in the English-speaking world).

Longbows are great in open battle, yes. But the hundred years war was a war of sieges and raids (by the English and the great companies), and for those the stonemason is infinitely superior to the longbowman.

For the French, the winning strategy was always to avoid pitched battles and fortify river crossing points until English armies had run out of supplies, then patiently retake lost fortified places through siege.

</comment><comment><USER32> An apparent preprint: [http://www.peterleeson.com/Longbow.pdf](http://www.peterleeson.com/Longbow.pdf)

<comment><USER33> Ok, we changed the URL to that from [http://www.journals.uchicago.edu/doi/abs/10.1086/684231](http://www.journals.uchicago.edu/doi/abs/10.1086/684231).

</comment></comment><comment> david-given Asimov wrote an essay on this back in 1980, called _The Unsecret Weapon_, in the collection _The Sun Shines Bright_. Same conclusion, IIRC.

However I've never found a copy online, which is a shame because I remember it has being one of his best.

</comment><comment><USER34> surprised there's no discussion of the importance of chivalric values in the French military. French knights were so married to the idea of valor that employing yeoman infantry was seen as dishonorable. Obviously this is directly related to the political context of state security but it's worth considering the cultural factor as well

<comment><USER35> Absolutely. The French nobility loved the heavy cavalry charge. The English knights had to fight on foot to protect the longbowmen. It's a totally different culture and attitude. You can't just pick one element out of a different system and expect to copy the successes of that system.

</comment></comment><comment><USER36> Last summer I did a workshop with the longbow. It's real fun, and has many links to meditation, finding your center etc. I had seen it before, never liked it, but it was great.

In the end I shot at a 1.5 meter target about 100 meters away. You could barely see it, as it was lying flat on a hill. At first I could not believe that I had the power to get that far, but it worked out. I missed it by about 12 meters, which was not bad looking at the competition that day.

<comment><USER37> You might like the book "Zen in the Art of Archery" by Eugen Herrigel, first published in 1948 / 1953 (German / English).

</comment></comment><comment><USER38> Makes me want to learn how to use the longbow.

It seems a challenge that this skill has been lost, and is interesting in that how long it took to develop.

<comment><USER39> I own one and they are very fun to shoot. But it take a lot of practice to be accurate with one. There is no sight or even an arrow rest on authentic english longbow so learning to shoot consistently takes a while.

</comment></comment><comment><USER31> A paper about the hundred years war that doesn't cite a single French-language source except Froissard? Not very serious.

</comment><comment><USER40> >Yet the Hundred Years War (1337–1453) lasted longer than a hundred years—plenty of time for England's enemies to learn that their defeats were heavily influenced, if not caused, by the longbow.

Didn't England lose the Hundred Years War? At least looking at the map before and after - it lost everything on the continent, incl. last remnants of Angevin and Normandy lost to France, with France rising up significantly bigger and stronger as a result of the war.

While long bow is a nice nostalgic weapon, the crossbow is technologically more advanced, and in our civilization technology wins :

"Plate armor that could be penetrated by large crossbows, but was impenetrable by longbows, was uncommon in Europe until about 1380"

(funny that while a child i was initially making bows, yet soon switched to making crossbows - and they were interesting until i made my first single shot handgun at the end of the 1st grade :)

<comment><USER35> Yes, England lost. The thing is, field battles don't really win wars; sieges do. At least when the war is about territory.

England did a lot of damage to France, but couldn't really hold on to the territory. And besides, it was really only a handful of field battles they won so spectacularly (not just due to the longbow, but due to a more comprehensive strategy involving longbows together with knights on foot and good defensive terrain).

</comment></comment><comment><USER41> It's funny how the article quietly assumes "Scotland+France+England" = "Europe".

<comment><USER42> Can you provide a concrete example ?

I really can't see this assumption made anywhere in the paper.

<comment><USER41> > For over a century the longbow reigned as undisputed king of medieval > European missile weapons. Yet only England used the longbow as a mainstay in > its military arsenal; France and Scotland clung to the technologically > inferior cross- bow.

> England alone, for a 150-year window in late medieval Europe, was > politically stable enough to render the longbow its rulers' optimal > technology choice. In contrast, in France and Scotland political instability > prevailed, rendering the crossbow the optimal technology choice for rulers > in these nations.

<comment><USER42> Yes, I read those, but I still don't see the assumption made.

The first more general sentence does not imply that the all the countries mentioned in the second make up the entirety of Europe.

It makes sense that the author would make a specific comparison with the countries involved in the war, rather than doing so for all the countries in medieval Europe.

<comment><USER41> Maybe I'm reading too much into this. It's just that I disagree with both sentences.

Mongol composite bows were superior ranged weapons and were used in Europe since 14th century.

And there were other politicaly stable countries in that period, including Teutonic Order, Poland, Venetian Republic among others.

<comment><USER26> Like the difference between crossbows and longbows, they were superior in some ways and inferior in others.

Since they were composite, they were dependent on glue and cord holding them together; they were somewhat more susceptible to weather. They were also more expensive to produce. However, as recurves they had better power with less stacking (force required to hold them at a full draw), and they were also shorter so could be used from horseback, a huge advantage for a nomadic people on the steppes.

Your point is well taken, however, that the paper is really only comparing a very limited portion of Europe over a fairly limited amount of time. It's an interesting analysis, but I don't think it has enough data or broad enough application to make it definitive.

</comment></comment></comment></comment></comment></comment><comment><USER43> Explains the large number of hackathons we have these days: "...a ruler who wanted to adopt the longbow had to create and enforce a culture of archery through tournaments, financial incentives, and laws supporting longbow use to ensure sufficient numbers of archers."

</comment><comment><USER44> I've only read the abstract, so I'm not sure if this is covered, but the longbow requires huge amounts of practice from a young age to be effective. You had to be incredibly strong just to draw the string. A crossbow, by contrast, was easier to draw, and men could be trained to use it in a far shorter time. English Kings had constant problems with procuring enough men capable of using a longbow, passing all sorts of laws banning all sports except archery etc. Perhaps the French simply couldn't find enough trained men?

<comment><USER45> > I'm not sure if this is covered, but the longbow requires huge amounts of > practice from a young age to be effective.

It is covered, the paper lists a number of measure the English crown took to force people to train with the longbow in their spare time.

> the French simply couldn't find enough trained men?

The French could have taken the same measures of mandating longbow ownership and strongly "encouraging" longbow training (by setting up tournaments and forbidding other types of leisure)

</comment></comment><comment><USER46> It's an interesting paper but "politically stable" isn't the right term.

A population able to defeat the infantry technology of the time requires a different social and legal position than one that doesn't have that ability. That is, the government needs more cooperation and consent of the governed. That government is stronger than other governments, because it can kill their armies. But it is more dependent on that population and so cannot abuse it in the same manner as those other, "weaker" governments.

</comment><comment><USER35> A historian friend claims this is bollocks. England was not significantly more stable, and the longbow was not a superweapon on its own. It was part of a system of combat, of combined arms, involving knights fighting on foot and choosing the right terrain.

And when they didn't have the right terrain, those English longbowmen also lost plenty of battles. They had some spectacular victories at Crecy and Agincourt, but they also had their fair share of losses.

Excellent weapon, but no silver bullet.

</comment><comment><USER47> Interesting discussion, including the comments below respecting how Barons didn't necessarily want an armed populice because it made it harder for them to stay in power. Does any of this sound familiar or applicable to today (gun control debate)??

</comment><comment><USER48> I fail to see their references to support the claim that france or scotland was more politically unstable.

Also how about the rest of european powers, I am not certain there is support that england was the only politically stable entity is europe during the middle ages.

<comment><USER49> Pages 699-702 address this in detail:

"The land (France) was divided into loose and shifting territories that owed little or no allegiance to any central authority, ruled across large swathes by noblemen who were little more than warlords" <USER2>
"Flanders, too, had great autonomy from the French monarch and strong ties to Germany and England (Sumption 1990, p. 35). In 1384 Flanders united with Burgundy to create a principality in France that fell in and out of French control for over a century." <USER2>
"Most critically, (Scotland) was bitterly divided into three warring parts: the English- speaking southeast, the Gaelic-speaking northwest, and the lands that fell between"

There's a bunch more detail there along with references to the papers they draw those conclusions from. I'd say they support that part of their argument soundly.

<comment><USER50> I think Scotland was split into a lot more than just three warring parts - there were battles between clans up to the 17th century!

[NB This probably explains why we have such an incredible number of castles here in Scotland.]

</comment></comment></comment><comment><USER51> "We determined the true solution of medieval war puzzle. The medievals truly had to reason just like we do. We cite no such reason in medieval literature sources, just use indirect proofs that we are right."

A good reason to laugh, I guess.

</comment><comment><USER52> The Brits have had the advantage of a technologically superior political system for a very long time. I usually make an argument that is quite similar to this to explain their rapid and unprecedented rise to imperial splendor.

<comment><USER53> As far as Europe is concerned: Roman Empire? Charlemagne? Otto? How is the British Empire "unprecedented" exactly? Is it a matter of scale?

<comment><USER52> Tiny little island that lost most (all really) of its continental holdings by 1700. Compare with other continental empires.

</comment></comment></comment><comment><USER54> tl;dr -- The longbow is worthless in most applications except military. The monarchy made it compulsory to train in bow use, so anyone recruited for the militia was ready in some shape or form to use the bow, so in a relatively short amount of time anyone can be trained to use a longbow for battle. They forced bow imports and kept prices very low throughout England.

The rest of the world couldn't enact such rules and thus could not make the Longbow a successful military weapon. It required years of training, not something you can do to a soldier who just got conscripted.

</comment><comment><USER55> Because France was playing Orc and researched lighter throwing axes instead.

</comment><comment><USER56> Anybody going to draw a parallel between this, and modern gun-control efforts? Or is that too contentious to be helpful in illuminating this centuries-old issue.

<comment><USER57> Here is a contemporaneous control effort:

 _We prohibit under anathema that murderous art of crossbowmen and archers, which is hateful to God, to be employed against Christians and Catholics from now on._

Canon 29, 2nd Lateran Council, held 1139, under Pope Innocent II

The council also forbade "jousts and tournaments". Apparently the original text has not survived, so only secondary sources and translations are available, some of which vary.

In any case, the prohibition appears to have been ineffective.

</comment></comment><comment><USER58> Interesting read of the introduction - and very good points. Perhaps yew was also way too hard to come by / expensive for the Scottish?

Also, it does make sense that training long term military personel was reserved to the ruling feudal class. Still, producing a longbow compatible population (of strong, loyal) men might have had other costs then political ones. Precision wise, a longbow is not a real tournament weapon - and you needed tall, strong men to wield it.

<comment><USER45> > Perhaps yew was also way too hard to come by / expensive for the Scottish?

One of the first point the paper makes is that the domestic supply of english yew was of poor quality and way outstripped by the demand, and the country imported yew from throughout continental Europe. So while yew availability may have been an explanation for Scottland, it definitely wasn't for France.

> Still, producing a longbow compatible population (of strong, loyal) men > might have had other costs then political ones. Precision wise, a longbow is > not a real tournament weapon

The longbow is a tournament weapon if you set up longbow-only tournaments and legally forbid other sport tournaments.

<comment><USER50> Golf and football were actually forbidden in Scotland for a time in the 15th century to try and encourage archery practice:

[https://en.wikipedia.org/wiki/Golf_in_Scotland#Etymology](https://en.wikipedia.org/wiki/Golf_in_Scotland#Etymology)

</comment></comment></comment><comment><USER59> It's nice to see the conventional wisdom confirmed for once, but... isn't this the conventional wisdom?

<comment><USER60> Is it? I always thought crossbows were _way_ more effective than longbows at range and accuracy.

<comment><USER59> I'm mostly thinking of the battle of Agincourt, which has long been celebrated in the English-speaking world as the victory of the common man over the elite, heavily armored knight, all thanks to the longbow.

</comment></comment></comment><comment><USER61> If anybody wants to go more in depth on this I suggest A Distant Mirror. Brilliant work.

</comment><comment><USER62> I thought this was going to be about the AH-64D Apache Longbow.

</comment><comment><USER63> Great paper. Nice to see the authors include Edward III's compulsory practice longbow after church on Sundays for two hours.

</comment><comment><USER64> Plain BS.

I learnt "canne d'arme and baton d'arme" the "fencing of the i-gnobles".

From feudality to absolute monarchy the raise of monarchy has been made at the costs of "Jaqueries". Peasant revolts of the "non nobles" "ignobles" in latin derived french.

The central control brought by the carolingien and then the bourbon as resulted in strong traditions: knights and nobility are also a force to squalsh revolts.

This and the dissolution of Lances towards "regular armies" after azincourt defeat (longbow involved) has been used to cut the fraternity at arms between feuds members. (Lances were like organic units of versatile men at arms doing their best to bring everyone alive the local feud included).

The strength of the knight were enforced like in feodal japan, by preventing the crowd to gain power.

For this, metal was considered the weapons of only knights.

Which means that when using the old franc laws for something as rude as sullying a women in a church out of the accepted "traditions", the divine judgement could be called ... a duel.

Needless to say peasants were not authorized to have metal ... officially.

So with all the jaqueries going on, you don't really want the peasants to have weired ideas about efficient wooden weapons.

And still monarchy was a vast joke at this time and era, cousins of the royal families were lending each others money, and were often tight by blood.

England had no interest to destroy the french society.

French kings had no real interest in defeating england. They were mainly aiming for weakening the local suzerain. The feuds.

Of course it backfired. Louis XIV almost get killed during the "fronde".</comment>


CoreOS Linux Is Now Container Linux by CoreOS - <AUTHOR> https://coreos.com/blog/tectonic-self-driving.html#coreos-linux-is-now-container-linux <comment><USER2> This name is conversationally awful. Previously one could trivially identify CoreOS as a linux distro to someone. Now what are they supposed to say? container linux? it sounds like someone misspoke, what is it you're saying? you use containers and linux?

There's absolutely nothing distinctly identifying in the new name, nothing distinguishing it from other words expected in the relevant topic of conversation.

And pointing out that keeping its name all lower-case is to be consistent with the rest of CoreOS projects is a bit weak when clearly everything else has a succinct and short identifying name then this black sheep ambiguous mouthful of "container linux" shows up. Come on guys!

And what is up with this new logo, what does it even attempt to represent? Clearly Tectonic is the new shiny and this didn't receive much thought or investment.

<comment><USER3> > This name is conversationally awful.

It's also entirely un-Googleable. Searching "CoreOS" would return you stuff only about CoreOS. Searching "container linux" will return you tons of other unrelated results, if you don't get carpel tunnel by the time you even finish typing it.

<comment><USER4> However, the inverse is probably what CoreOS is going for.

Now, whenever you google "linux container" you'll get "container linux by coreOS" as one of the top hits (currently, for myself, googling "linux container" doesn't have coreOS on the first page).

<comment><USER5> That would be a good point as a question but as an idea it's naive. Unless they increase their popularity by several times they never displace any of the current top search results.

<comment><USER4> CoreOS is fairly popular isn't it?

</comment></comment></comment></comment></comment><comment><USER6> That name sounds descriptive, which could be a problem with respect to trademark protection. (Descriptive names are more difficult to protect.)

I'm frankly surprised the lawyers signed off on it.

<comment><USER7> _" The Linux Foundation protects the public and Linux users from unauthorized and confusing uses of the trademark and authorizes proper uses of the mark through an accessible sublicensing program. The Linux Foundation offers a free, perpetual, world-wide sublicense to approved sublicense applicants. In return, the sublicensee holders must agree not to challenge Linus Torvalds' ownership of the Linux mark in any jurisdiction, and to provide proper attribution of ownership on their goods, services and elsewhere. The Linux Sublicense Agreement is available for review."_

[https://www.linuxmark.org/](https://www.linuxmark.org/)

<comment><USER8> The parent meant that they could protect CoreOS ([http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4805:a60...](http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4805:a60d9j.4.2)), but might not be able to acquire trademark for Container Linux, because "container" is a descriptive term. Like, you can protect "Colgate", but not "White tooth paste". Pretty sure, though, they know what they were doing and consulted lawyers :)

<comment><USER9> Linux is a trademark, toothpaste is not, that's the difference. You could definitely trademark "Black Colgate", "Ubuntu Linux" and "container linux", the latter two via the Linux sublicensing program the comment above yours linked to. IANAL.

<comment><USER10> The sublicense agreement just means you get to use Linux in your name. It doesn't mean you get to protect your new name with your own trademark. That's up to the law.

</comment></comment></comment></comment></comment><comment><USER11> I'm guessing they're shooting for a name assocation thing here, the same thing that Microsoft pulled off with SQL Server associating the generic term with a specific product.

However as others have said, searchability for that product name is awful and I'm not sure they're not a little late in the game to try this trick. Googling container linux at the moment and they're not even on the first page of results...

I've had a look at CoreOS in the past and it's interesting but very geared towards cloud/large deployments (e.g. by default there is no way to use a password to login after intallation, you need to use automation and setup an SSH key), makes it kind of hard to tinker with in a desktop env. though.

<comment><USER12> I do not have an opinion on whether CoreOS is geared towards large deployments. However, I very strongly disagree with the example you give. Every person who does Ops work has an SSH key. Creating one and keeping it on your laptop/desktop is not hard. Not allowing any remote password-based authentication is very helpful for security _of non-large deployments_ too (or even more helpful for them).

<comment><USER11> I didn't say I thought key based logins were bad, but that not allowing a password login during setup made it more awkward for people trying out CoreOS to test.

That said I wouldn't say that SSH key based login were necessarily great for large deployments, one lost key+passphrase ('cause everyone totally always has a good passphrase on their SSH keys right) and an org. can be in for a world of pain, as in many cases the procedures for key management of SSH aren't well formalized.

<comment><USER12> > I didn't say I thought key based logins were bad, but that not allowing a > password login during setup made it more awkward for people trying out > CoreOS to test.

Especially if it's awkward, it's good to force this immediately. Thus "test deployments" will not evolve into real ones while keeping the possibility of password-based authentication.

You can also argue that disallowing empty password for remote access makes things more awkward (which is true). Yet, I expect that you are very happy with systems that do so.

> That said I wouldn't say that SSH key based login were necessarily great for > large deployments, one lost key+passphrase ('cause everyone totally always > has a good passphrase on their SSH keys right) and an org. can be in for a > world of pain, as in many cases the procedures for key management of SSH > aren't well formalized.

You are arguing that the situation is bad with keys, while ignoring the fact that the situation is much worse with passwords (seatbelts are annoying and people still die in accidents; yet, they're useful):

If you allow passwords, the situation is the same, except you don't have to lose the key too.

Also, password reuse between different systems in the same deployment is usually rampant, which makes it very easy for an attacker to jump between such systems (just wait until someone logs in remotely to a compromised system and you have the password).

If the situation with keys is bad enough for you, then you can use SSH certificates, which require you to just protect the CA (It is, unless you need revocations, very simple to set up. You can get by without revocations by having an automated CA that gives you certs with a validity of something like an hour.)

<comment><USER11> I'm not ignoring password problems I didn't make any mention of passwords one way or the other. You seem to be ascribing views to me that I just didn't state, I'm guessing this is you assuming my world view, a common issue with Internet discussions.

I didn't say passwords were good, I said that people often overlook the weaknesses of managing SSH key based deployments. key proliferation is a real issue and as passphrases on SSH keys are susceptible to offline attack, without very strong passphrases they can present a risk. Also in my experience centrally managed key rotation and expiry is rarely included, thus the risk that if a key is compromised, detection/revokation/re-issuance are hard.

To provide some background I've been an IT security professional for 15 years, I know the ups and downs of various authentication mechanisms, I was just pointing out a rarely noted downside of SSH key based auth. given you seemed from your comments to view it as an unalloyed good.

<comment><USER12> Ah, I see where the disagreement lies. I've thought that by downsides you mean _relative_ downsides, whereas you meant absolute ones. Thanks for the detailed explanation of your position.

</comment></comment></comment></comment></comment></comment><comment><USER13> Ubuntu is container linux for me. I WANT to install stuff on my host; thank you apt. CoreOS produced etcd which is outliving the OS distribution.. Fleet was a thing.. Their update system.. This pivot away from the distro makes sense.

<comment><USER14> CoreOS is still _very_ much a thing. The update system is seamless and has never once caused a hiccup for me. And I certainly don't perceive this as a pivot away from the distro, at all. Not sure where any of your statements come from. Except the Fleet bit, maybe, but that's just because they saw something better in Kubernetes and now contribute heavily to it.

And I'm curious what you want to install on your host if you're using containers. Surely you're not logging into these VMs interactively?

(A bit funny too, Ubuntu's fork of docker in Xenial was causing a reboot of basically everything under systemd (including ssh) under certain conditions used in Kubernetes.)

<comment><USER15> Where is the statement that they are moving away from fleet? There was no mention of anything related to that in the linked article.

<comment><USER14> Sorry, I didn't mean that. My perception is that I see far less announcements about Fleet, but I don't know any official stance or anything. Didn't expect it to have as much activity as it does on GitHub, but the most frequent recent committer doesn't seem to be an employee (again, that doesn't necessarily mean anything). I was mostly agreeing that I don't see Fleet as a super popular tool these days (contrary to features they've contributed to Kubernetes or the ecosystem, etcd, coreos, flannel, etc)

<comment><AUTHOR> This is roughly correct. The README says it best: [https://github.com/coreos/fleet#current- status](https://github.com/coreos/fleet#current-status)

Also, as you mention there are very compelling reasons that when Kubernetes came on the scene 2 years ago we started contributing heavily instead of trying to compete. We started to say something with fleet and Kubernetes completed our sentence: [https://github.com/coreos/fleet/blob/master/Documentation/fl...](https://github.com/coreos/fleet/blob/master/Documentation/fleet-k8s-compared.md)

Overall, we recommend everyone use Kubernetes as the way to orchestrate containers.

<comment><USER16> Personally I feel it's a shame - Kubernetes is way overkill for most of the deployments I do. At the same time fleet has a number of annoying problems even on (or even particularly on) small clusters.

I see Kubernetes deployments where more of the containers running are there to provide infrastructure than actual workloads, which gets just silly. For small deployments like that, something as simpl as Fleet but with a better scheduling story would be preferable to me.

But I get that those kind of deployments won't pay the bills as they're certainly much less likely to pay for CoreOS services.

<comment><USER17> Indeed if you have just a handful of hosts, spending gigas of ram for kubernetes is not really exciting.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> I was going to read the site to see what they are up to, but, grumpy old man that I am, I no longer feel the need to push through sites done in low- contrast text. If they don't want it to be readable, I won't read it...

<comment><USER19> I'm not sure what you mean. I see black text on a white background.

[http://imgur.com/BDXuFXj](http://imgur.com/BDXuFXj)

<comment><USER20> That's grey on a white background. This is what it would look like if it was black (I removed the "color: rgba(0,0,0,75)" tag via chrome's inspector): [http://i.imgur.com/v491foi.png](http://i.imgur.com/v491foi.png)

It looks like your rendering (resolution, dpi, hinting? no idea) mitigates the effects of the reduced contrast in a way that mine do not. I'm guessing that's true on their developers' systems as well.

</comment></comment></comment><comment><USER21> There logo and brand is great. It was one of the logos/brands I used yesterday for a gig I had designing a logo for a VR startup-- and CoreOS was my favorite.

It was minimal & likely unique enough for trademark and clean. I like it. This is a terribly verbose pivot and pretty bad as far as rebrands go.

</comment><comment><USER22> Does the logo remind anyone else of Pacman?

</comment><comment><USER23> i think the name change makes sense and it's a power move, it basically says: hey if you want to run containers on linx, we are -the- software to do it instead of just one among many. this only works if you're already fairly established and I think CoreOS has some justification to do it

</comment><comment><USER24> Ok, the sky is not falling. "CoreOS Tectonic" is their _googleable_ paid enterprise OS product, and now "container linux by CoreOS" is the free offering.

The move is clearly designed to push their free offering lower in the search rankings.

</comment><comment><USER25> I wish the logo didn't set the C and L in lowercase.

<comment><AUTHOR> I can see that. It does make a bit more sense when placed alongside the other wordmarks [http://i.imgur.com/4hqbVG4.png](http://i.imgur.com/4hqbVG4.png)

<comment><USER26> I hate the Container Linux logo! Also, why does etcd's doesn't any reddish element?!

</comment></comment></comment><comment><USER27> In 3 - 5 years, the name will sound archaic.</comment>


Ask HN: One week no distractions - what are you dying to get done? - <AUTHOR>

HN<p>If you had one week vacation, with no distractions - what would you do? <comment><USER2> Finish my API and the underlying code generator algorithm and take the time to refactor a few things that I am not satisfied with.

And learn python :)</comment>


Not only Android, Windows 10 Mobile Build 10240 packs Linux core files too - <AUTHOR> http://www.nokiapoweruser.com/not-only-android-windows-10-mobile-build-10240-packs-linux-core-files-too/ <comment><AUTHOR> The article claims that there is a file named LXCore.sys in C:\windows\system32\drivers which contains the following strings

        initrd=/initrd.img root=/dev/ram0 rw androidboot.hardware=hyperv console=tty0 console=ttyS0 video=hyperv_fb:1024×768 BOOT_IMAGE=/kernel
        Linux version 3.4.0-Microsoft (email@example.com) (gcc version 4.7 (GCC) ) #1 SMP PREEMPT Wed Dec 31 14:42:53 PST 2014</comment>


Subrosa Warrant Canary - <AUTHOR> https://subrosa.io/canary

<comment><USER2> The trouble with warrant canaries is that you have no way of knowing if someone forgot to update it or if it's intentional; in some cases, it's even more suspicious for it to be updated once attention has been drawn to it.

The fail cases are indistinguishable from the successes in some circumstances.

<comment><AUTHOR> Yeah, I know... I wonder if there's an improvement on the canary system somehow. You can't tell if it's just a page left by the wayside or an important clue...</comment></comment>


Nitter: A free and open source alternative Twitter front-end focused on privacy - <AUTHOR> https://github.com/zedeus/nitter/ <comment><AUTHOR> Features listed in the github page:

* focused on privacy

* no JavaScript or ads

* all requests go through the backend, client never talks to Twitter

* prevents Twitter from tracking your IP or JavaScript fingerprint

* unofficial API (no rate limits or developer account required)

* AGPLv3 licensed, no proprietary instances permitted

* lightweight (for @nim_lang, 36KB vs 580KB from twitter.com)

* native RSS feeds

* mobile support (responsive design)</comment>


Clinkle: App Teardown (Part 1) - <AUTHOR> http://svstealth.tumblr.com/post/54198052713/clinkle-app-teardown-part-1#

<comment><USER2> 1) I'm not familiar with intellectual property law and I'm curious: Can Clinkle's lawyers do anything to prevent such information from being published?

2) My inner conspiracy theorist says this is a clever posting from someone internal to Clinkle as a PR stunt.

<comment><USER3> > 2) a PR stunt

Came here to say just this. This looks very much like an astro-turfing post.

<comment><USER4> i don't think astroturfing posts are typically this negative..

<comment><USER3> It'd be a better way to astroturf actually. The goal of such post would be to merely put the company on a map and get people talking about it. Just set in a mood for now - it's something grand, mysterious and ambitious, if a bit half- baked (but that's just at the moment, that's why they are in "stealth" mode after all). The praise singing chorus will step in later.

</comment></comment></comment></comment><comment><USER5> Continued here: [http://svstealth.tumblr.com/post/54200406550/clinkle-app- tea...](http://svstealth.tumblr.com/post/54200406550/clinkle-app-teardown- continued)

This part just mentions design, possible parter logos, fonts, facebook like boxes and that they didn't obfuscate code.

</comment><comment><USER6> Article seems unnecessarily mean.

A $25m "seed" is generally not a good idea but I think worthwhile giving the benefit of the doubt at this point and waiting to see what and how they roll out.

The Yodlee thing is likely for verifying bank/card accounts, not offering Mint-like services.

</comment><comment><USER7> With android apk's can so see the complete source code of the app?

<comment><USER8> No, but you can disassemble them to see the Dalvik bytecode[1], which is not too hard to understand.

[1] [http://source.android.com/tech/dalvik/dalvik- bytecode.html](http://source.android.com/tech/dalvik/dalvik-bytecode.html)

<comment><USER9> You can actually reverse engineer an entire app to java code and see all the resources such as strings and images. Just takes around 10 minutes [http://stackoverflow.com/questions/3593420/android- getting-s...](http://stackoverflow.com/questions/3593420/android-getting- source-code-from-an-apk-file)

You can prevent this by obfuscating your code in eclipse with proguard, however most apps are not obfuscated.

<comment><USER10> Even with obfuscation you tend to just end up with the code, but all the identifiers are replaced with a, b, c, etc.. I've still been able to figure Bluetooth protocols and other things without much trouble. For pirates, impersonators, and malware creators, they often just have to find free/pro/goods counter/license check/sig check or add in a call to their own extra code to run. So a little tougher for them, but not the end.

</comment></comment></comment></comment><comment><USER11> Wow... blindly speculating yesterday about what Clinkle might be doing -- [https://news.ycombinator.com/item?id=5956736](https://news.ycombinator.com/item?id=5956736) \-- I'd thrown in "ultrasonic acoustics" as a random wild guess. Great to hear that's part of it.

Though it'd also be kind of cool to do the transaction in the hearable range... so your phone playing a merchant could make the same sort of 'honking' as old dial-up modems. Not just a novelty, that'd promote the service to everyone within earshot.

</comment><comment><USER12> This is a worse investment than color in my opinion. The founders have no track record whatsoever to justify a $25M investment for a product that has been stealth mode for two years running. I've heard several complaints from insiders about the company and its founder.</comment>


Does the media backlash to Musk's idea mean it's disruptive? - <AUTHOR> https://www.quod.us/article/why-does-elons-media-ratings-idea-offend-journalists <comment><USER2> The cynical view would be that Musk is another Silicon Valley billionaire who wants to use his money to bully media outlets that publish reports about him and his company that he doesn't like.

<comment><AUTHOR> I can see why journalists might be concerned about that, but I think whatever he creates should be judged for what it is - it's possible he has good intentions.

<comment><USER2> It's possible--but his public actions suggest he doesn't have an unbiased view.

</comment></comment></comment><comment><USER3> I think, it is a nice idea and it's necessary due to increase of fake news, or paid news. Also I don't think it's the only solution but it may be the simplest way to counter.</comment>