Software bloat makes me sad - <AUTHOR> http://www.remarkablyrestrained.com/articles/-software-bloat-makes-me-sad/ <comment><USER3> There is another side of extra resource use that I don't really see addressed except in the mobile space: ecology.

Even though my computer can run all applications without a hitch, it is still very wasteful to constantly use CPU power because of technology choices or plain laziness. As an example, Spotify and Slack are two applications that seem to use most of my CPU after Chrome. Spotify and Slack combined seems to hover around 5-15% of total CPU (a two year old i7). When there is a lot of traffic in Slack I have seen it using 15-20% by itself, with multiple processes running and memory use going above 200 megs.

Both applications work smoothly, but should they really use that much resources? A chat application? A music player? With modern CPU's I would expect them to be at the bottom of the process list when sorted by CPU usage. I used IRC on my Pentium 75Mhz and it ran fine. When simple applications are made so poorly that they use that much resources, what is the worldwide impact of that power use? And what about the users that don't have powerful and expensive CPU's?

<comment><USER4> It's not that they have poor algorithms or whatever, it's that they're part native, to handle the desktop interaction and the rest is a bunch off html/css/JavaScript running in an embedded browser. At least that's how Spotify works.

The problem is that our tools for making multiplatform native GUI's suck so bad we'd rather just embed an entire Web browser into everything.

<comment><USER3> There are some okayish cross platform frameworks, such as QT and even JavaFX. One of the main complaints of cross platform GUI's has been that they don't work like native applications. But for some reason nobody cares when the app works like a single page web app, which in many cases is a lot worse than even plain old Swing apps. Which at least supports right-click properly.

I think the main reason that node-webkit and what-not are popular, is because of web developers moving to native app development. It's really easy to get started that way, and you can even share code with your web app. Where something like QT has a really huge learning curve for programmers transitioning from Javascript.

About poor algorithms. I actually worked on optimizing a well known web browser for a couple of years. And most of the stuff we did, was because of really bad Javascript code. Even though it seems gluttonous to embed a web browser in applications, and even insecure, it doesn't have to be as bad as it is, especially with a simple application like Spotify. This is going on a bit of a tangent, but every frontend programmer should at least learn how the browser actually works, a nice site for that is [http://jankfree.org/](http://jankfree.org/)

<comment><USER5> > There are some okayish cross platform frameworks, such as QT and even > JavaFX. One of the main complaints of cross platform GUI's has been that > they don't work like native applications. But for some reason nobody cares > when the app works like a single page web app, which in many cases is a lot > worse than even plain old Swing apps. Which at least supports right-click > properly.

There's more to non-nativeness than just look and feel, which the more mature cross-platform GUI toolkits can ape fairly well. Another concern is accessibility for people with disabilities, e.g. blind people using screen readers. Qt, for example, is kind of accessible on Windows, Linux, and Mac, but not at all on mobile platforms. Not sure about the status of JavaFX. At least a single-page rich web app can be made accessible using the ARIA extensions to HTML, and if you use one of the big four web rendering engines, you can be sure they've done the hard work of implementing the underlying OS accessibility APIs well. Of course, many (most?) web developers don't implement ARIA for their custom UIs.

<comment><USER3> Accessibility is a point I didn't think about at all. Thanks for reminding me, it's really something that is all too often forgotten. JavaFX supports ARIA and all standard controls have accessibility built-in. But I have no expertise to actually comment on the quality of accessibility features in JavaFX.

</comment></comment></comment></comment></comment><comment><USER5> I've previously decried bloat too, but I find that my rants against software bloat are based on emotion, not reason.

So, looking at this rationally, consider your favorite lightweight window manager or desktop environment for Linux. Is it fully internationalized, including support for CJK input methods? Is it fully accessible to users with disabilities, e.g. blind people and people with mobility impairments? Does it auto-mount USB thumb drives? Does it do all of the other things I'm not even aware of that are required for a fully usable desktop environment covering a wide variety of machines, users, and use cases? AFAIK, the only Linux desktop environments that come close are GNOME and Unity.

Basically, the world is complicated, so real-world software has to be complicated too.

It sounds like Atom could still use some optimization though.

<comment><USER6> > AFAIK, the only Linux desktop environments that come close are GNOME and > Unity.

I'm the project lead of LXQt. All those things you listed can be supported without introducing much bloat at all. In DEs, most bloat comes from pure technical debt. Unnecessary libraries, duplicated code/libs, etc.

Feature bloat is another matter and is more subjective. A lot of it is down to UX.

Fun fact: KDE 4.x depends on ruby in most distros. Do you know why? Dolphin ships with a ruby script to update some folders (don't remember what it does). Nobody runs it. That's it.

<comment><USER7> > Fun fact: KDE 4.x depends on ruby in most distros. Do you know why? Dolphin > ships with a ruby script to update some folders (don't remember what it > does). Nobody runs it. That's it.

Why did they allow an additional dependency on Ruby in? It seems like perl or python would be the more logical choice, given they'd already be on the system (heck.. maybe bash?)

<comment><USER8> Probably because a Ruby activist wrote a cool script and no-one cared about the implications of a new dependency at all.

<comment><USER9> I fear many projects seems to take the infrastructure and manpower of large distros for granted these days.

</comment></comment></comment></comment></comment><comment><USER10> >The usual counter to this is that the actual (as opposed to imagined) bottlenecks will only become apparent after intense usage.

The usual counter is that "optimising" takes time. And all of the time that you're spending trying to optimise before release is time that no one is able to use your software at all.

And the reality is that a lot of the bottlenecks _can 't_ be predicted in advance - who knows how may files the average user might want to load into your system, or whether your website is going to attract 100 or a million users a month? And many expected bottlenecks become largely irrelevant as technology moves on.

Take his Ubuntu example - for what percentage of users does the fact that it doesn't fit on an actual CD really matter any more? Is it worth spending weeks or months fine-tuning the distro to a point that it can be fitted onto a medium that most people probably aren't even using anymore?

<comment><USER11> I could edit a doc with a word processor that could fit onto a floppy, and it worked well. Now, why does the same task require a multi GB pos bloatfest to do the same job? And oftentimes, more slowly! Imagine for a second, the power of today's hardware running optimised lean code. It could be so good, but we accept bloated crappy bug ridden shitfests of OS and application software. We seem to care more about glossy and social then performance. It is a real problem.

<comment><USER12> If I want to start Microsoft Word right now, here's what I have to do: I press the Windows key, type "word", press enter, and then wait for it to start. That entire process takes three seconds; I just timed it. Now that Word's been run once already, I can start it again in less than one second. That compares pretty favorably with the process of finding a floppy disk, inserting it, and then finally running a command on it (it's even worse if I don't remember the cryptic command name, because then I have to wait for the floppy's directory to be read). To say nothing of how much easier to deal with this "bloatfest" will be once I get it loaded, compared to your leaner alternative.

<comment><USER13> That's probably because you have SSD, but anyway; I could do the exact same process 10 years ago (with "winword" instead of "word"), get similar response times, and yet the software was an order of magnitude smaller _and_ more responsive. And it's not like Word gained many actually useful features during that time.

<comment><USER14> >> And it's not like Word gained many actually useful features during that time.

Then use the 10 year old version! Unless, of course, one of those few "actually useful features" is something you can't live without.

A _lot_ of people use Word for a _lot_ of use cases. The value of an added feature that someone needs always trumps the performance cost of adding it until the performance becomes so bad that it becomes the reason that other people _stop_ using it.

<comment><USER15> People who complain about bloat are usually complaining about features they don't use. Of course watch what happens when people start doing metrics and optimizing their UI for "common uses" \- turns out you're optimizing for non- existent users (see: the Ribbon).

<comment><USER16> The ribbon gets knocked a lot; but the median word processor user has zero experience. The ribbon gives them a fighting chance to find what they need. At the expense of 'expert users' with their idiomatic expectations.

<comment><USER13> Which is a problem because tools should be just that - tools. You don't make welders or soldering irons easy for people with zero experience. You make them effective and efficient tools, and then _train_ people to use them. Heck, show me a single musical instrument giving zero-experienced users "a fighting chance to find what they need".

It's weird how new trends in UX design try to make a first-time user become a genius immediately after double-clicking on the program icon. The only way you can do that is by dumbing down the software to the point it can actually be comprehended this way - which makes it much less usable and effective as a tool.

<comment><USER16> That's the expert talking. The tool is made for the most common case - a new hire meeting it for the first time. They're not gonna do a good job; but anything that can improve their performance, pays. Follow the money.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> I'm not really convinced. Leaving aside the argument about whether or not software is 'bloated' at all, or what 'bloat' actually means, this in particular stands out:

 _"wouldn't it have been easier not to create the problem in the first place?" It would seem obvious that the answer to this is indeed "yes"._

It doesn't seem obvious at all, especially considering the implicit assumptions about whether or not bloat is actually a problem. There are three classic examples highlighted in the article of writing about this tradeoff: "Make it work, make it right, make it fast", "Premature optimization is the root of all evil", and "Bloatware and the 80/20 Myth" – but the argument about why these don't apply is a bit weak: "bloated software simply makes me sad".

To be honest, I don't find we've got a problem, generally. My experience with my computer is that I can do many more things much faster than I could in the past. And I don't think that counts as bloat.

<comment><USER13> I came to believe there are two types of programmers - those who get emotionally upset about ineficciencies, and those who couldn't care less. I'm in the first camp, so I understand the feelings of the author perfectly.

You say your computer can do "more things much faster" than before - <USER2> imagine how many more things, how much faster you could do if the software didn't bloat itself up almost at the same pace as the hardware gets faster.

And you see, I can understand abstraction layers. I can excuse coding for function first, speed second. But then there's the kind of bloat that can only be explained by programmers having no clue about what their software is doing. There's literally no reason why an article should lag in your browser, or Spotify should take 10+% of CPU on standby. There seems to be a lot of pointless code that's being executed, and nobody cares, because developers often have powerful machines. Not so the general population who then has to endure such creations.

<comment><USER18> As demand for software grows, a lot more code made by immature (as in beginner, junior, green) developers finds its way to production.

Part of it is not code reviewed by senior developers. Another part is but too late in the cycle and goes in anyway because features.

The bloat is technical debt accrued in favor of shipping.

It probably happens to both types you described, but shipping is a business decision.

<comment><USER19> It's not always a business decision. GNOME, KDE, X, systemd, dbus... The list goes on and on. None of this software is business derived.

Honestly, an engineer that cares about the performance of their code has several options available: \- design the project first, then code later. \- design the code for the architecture (arrays of objects vs. objects of arrays). \- use tools that can optimize out inefficiencies. \- hand optimize after writing a functional slice. \- document the APIs and interfaces to explain the performance expected as part of their contract.

Unfortunately, it seems as though we've gotten into a bit of a rut when it comes to this -- we rely on the awful tooling we have to optimize the code we write (yes, LLVM and friends are light years better at this than GCC et. al., but it's still not enough), we never document performance characteristics of the libraries and APIs we create, and we (at least in the OSS world) almost never design our projects to the level of detail necessary to fully understand it.

Honestly, I'm not sure how we can solve these problems if the engineers have a lack of discipline. It's a hobby, after all, right? We do this in our spare time, and nobody wants to write designs or document because that's the least interesting part of coding. See also GTK's autodocs, which for /years/ lay around as nothing more than a simple enumeration of which functions were in the libraries. Even in self documenting languages we fail at this (I'm looking at you, Common Lisp).

Optimizing afterward is a simple, if lazy, way out but post-facto optimization can only take you so far if the design is simply broken.

Since we never document or design, the problem ends up falling to our tooling. Things like oprofile and so on work, but are usually so coarse grained that digging through the code to instrument it effectively becomes a grind nobody wants to do. Maybe we need companies to develop free and open tooling for understanding the performance characteristics of the code we write. After all, the "modern" tooling we use for languages like C and C++ hasn't changed since the 80s, and it's often actually hostile to the end user, which just makes the job harder. Even our linkers often fail to do their jobs of optimizing out useless dependencies or symbols unless we explicitly tell them to do so.

Ultimately, the blame lies with us, the engineers who work on this code. New engineers joining our projects need to understand the code itself through and through. Our projects have become so large that without documentation no-one can make a clear, clean decision on what should or shouldn't be written anymore.

What I want to see is tooling that can semantically understand the code I write, and give me characterizations of the function calls I make as I write them. When I need to examine source to better understand it, I want tooling that tells me how often the functions are called, where they are called, and how. Raw text is great for writing prose, but we're not writing prose -- we're writing code. Our tools should reflect this, and give us as much help as possible.

<comment><USER20> Civilian comment: the Gnome/dbus/logind/systemd situation seems to have arrived as a result of a number of _independent_ projects each on their own random walk but responsing to the earlier states of other projects that each depends on. So it may be overall integration issues (Linux based systems have always seemed to me as a user to be like bags of lego) rather than efficiency of any particular aspect of one project.

<comment><USER19> While I agree they're all attacking the same problems, ultimately they all have exactly the same problem when it comes to code: no designs, no docs, and no tooling.

The point you make about Linux systems being bags of Lego is interesting. That's exactly how it is supposed to be. Unfortunately, the projects we're talking about don't compose well -- they're more like Duplo than Lego because often times they subsume whole feature sets into one huge monolithic block. Huge lumps of code exist in GNOME and KDE and systemd and dbus that just simply have no business being in there.

Dbus and systemd especially fail at the whole design angle.

<comment><USER20> Not sure why you are being down-voted for expressing an _opinion_ about program design. Would downvoters care to explain?

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> One thing that strikes me is the explosion in dependencies in most software. I'm guilty of this, too. I've seen plenty of examples where an entire library or framework is added to a project just for a couple of features. Add a few libraries like that and suddenly you have a few megabytes of additional libraries, where maybe 90% or 95% of the features will never be used. A good article a while back looked at common unix utilities, comparing the size of commands like cp from the 1980's to the present. Most of the bloat had to do with features that almost nobody ever uses. It wouldn't be so bad if everyone used the same set of libraries. For example, almost all applications have a dependency on certain core libraries like libc.

But we often use different libraries that do essentially the same thing or different versions of the same library, so instead of 1 copy of libfoo.jar, I have 2 copies of libbar.jar and 4 copies of libfoo.jar that may all do essentially the same thing. Then I have essentially the same functionality in C++ (some libraries that wrap collections), Python (where maybe one of they python versions wraps one of the C++ libraries, but a different version). And of course I have a version installed in each ruby environment. Add to that their dependencies, and the dependency's dependencies, and you have a perfect storm of craptastic. So libfoo.jar version 1.2.3 depends on libbaz.jar 2.3.4 which depends on libqux 1.5.7. Let's say each one is 250k, and all I ever used was some list sorting utility in libfoo.

But I don't know what we could really do about it. You can't force everyone to program in C++ or limit them to a set of blessed libraries. I think maybe developers could be more judicious about when they could add a few lines of code and when they actually need to bring in a hard dependency an an external library. And it happens with commercial software as well. Maybe this is just the way the world will be.

<comment><USER22> Dart makes a decent argument for a smarter compiler. They've implemented "Tree Shaking" in their compiler: essentially cross-library dead code elimination.

This would probably be quite tricky in Java land where reflection does add new entry points, but it could be used to solve the problem of "I only need this one function from this library, don't compile in anything else".

I was personally quite surprised when I ported from code from Node to Java/Groovy and the resulting shaded JAR was > 70MB, I think at some point it peaked above 110MB. I don't know what I changed, but it's down to 35MB now. But the code that we've written in house on that codebase boils down to 1MB. But besides figuring out that I don't want to make local builds I scp to staging (because scp is terrible), these numbers are all completely equivalent for writing server-side software that runs on dedicated machines.

We could certainly make it more efficient, but there's exactly zero business case for it.

<comment><USER23> You can only tree-shake a whole program compilation, but then you cannot use compilation units, modules and modularity efficiently. You have to choose one or the other.

Every normal compiler implements simple (i.e. module level) dead-code elimination already.

EDIT: Of course you could use static libs, which does pull in only used symbols, but then you cannot share them across apps and update independently.

I implemented a tree shaker for my lisp and was very happy with it, esp. for delivery. Like Go does it nowadays.

<comment><USER22> Right, I guess I wasn't clear, this was a shaded/fat jar, so it had all its dependencies included statically.

I feel like our computing infrastructure has gotten to the point that dynamically linked libraries are no longer a good choice. I think dynamic linking has only caused us problems at work (devs install Node deps on the staging server, forget to tell ops, service crashes when deployed in prod), and the memory/disk/transfer overhead are practically irrelevant at this point. The only remaining reason to have dynamic libs is the idea that they can be updated without help from upstream, but that really only works if the software is compatible with the latest libraries, which isn't always true.

Supposedly ProGuard has some cross-module dead code elimination for JARs, but I haven't tried it: [http://proguard.sourceforge.net/](http://proguard.sourceforge.net/)

</comment></comment></comment></comment><comment><USER24> As someone who is also saddened by software bloat, I also wondered a bit about where it stems from. There are of course the usual suspects (some of them mentioned in the article), but I think it boils down to another symptom of the modern rat-race culture, and it is not limited to software. When the goal of creating beauty and enjoying (as well as taking pride in) the creation process is replaced by the god of money and getting it out the door as fast as possible, the quality of the thing you're getting out the door has to deteriorate. I'd argue that a side effect of this is that the quality of life of both the creator and the receiver of the product decreases, but that is not immediately apparent when you're too busy trying to win a rat race...

However, I'm optimistic. For one, I think that the tools we have today are superior in absolute terms (convenience, speed, ease of use etc.) than they ever were. Of course they are not exponentially better (like the hardware they run on), but they _are_ better. Also, occasionally I see some gems here and there. There are still many developers who take pride in what they do and I enjoy finding that diamond once in a while when searching for an alternative technology to use in a new project.

</comment><comment><USER25> I agree in general, but the 'vim in combination with a few small plugins may lead to your whole computer locking up' is extremely misleading.

It's the _editor_ which has frozen, not the whole computer. And the plugin in question is a fairly complex autocompletion / analysis plugin for python. There's a bug listed in that thread, to do with it scanning all the files millions of times, but the big problem actually isn't bloat, in this instance, it's the non-async nature of vim. neovim should, I hope, solve the 'totally unresponsive' problem, and hopefully someone fixes the rope/vim interaction re-scanning all the files bug.

But it's not bloat, per se.

If your whole computer is locking up due to this, then that's a scheduling issue, and you could try switching scheduler, or lowering the 'nice' priority of that program.

Not that we should have to care about such things - that's pretty terrible.

</comment><comment><USER26> "Convenient though it would be if it were true, Mozilla is not big because it's full of useless crap. Mozilla is big because your needs are big. Your needs are big because the Internet is big. There are lots of small, lean web browsers out there that, incidentally, do almost nothing useful. If that's what you need, you've got options..."

[http://www.jwz.org/doc/easter-eggs.html](http://www.jwz.org/doc/easter- eggs.html)

<comment> vezzy-fnord That doesn't excuse resource inefficiency, which is really the main point. The issue of size can be further addressed by separation of mechanism and policy, and building for extensibility.

<comment><USER15> Are you sure there's inefficiency? Do you have specific points in the code or behavior which are obviously inefficient, or does it just feel "too big"?

<comment><USER19> _ahem_ MorkDB.

There's tons of code in Mozilla that isn't necessary to do the one job the browser was built for.

I don't need code that manages bookmarks. At all. I don't need code that stores history for years. Honestly, I don't /want/ cookies persisted /at all/. I don't need themes to browse the web, and a reorganizeable UI is /never/ what I'm looking for in a browser.

I don't need WebGL. I don't need Canvas. Hell, I definitely don't need syncing of all this extra bloated data around to services somewhere in the 'net, either. Frames? What about _floating frames_?

Half this stuff is better left to tools that are built for it, the other half is junk I don't need, or is junk that actually creates more problems than it solves.

<comment><USER27> Then use something else. It's not like you don't have a choice.

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

Based on your stated requirements, perhaps you'll like Dillo.

[http://www.dillo.org](http://www.dillo.org)

<comment><USER19> I think you misunderstand. The parent was asking for examples of bloated code. I was providing examples.

I actually /do/ use other browsers like Midori, w3m, and surf. The problem doesn't disappear, though, because it's up to all of us writing code to be better at it.

<comment><USER27> Not all code bases need to be minimal to be valid. Some people like having the features you class as superfluous. So long as you have the option to choose software that suits your taste there's not really much of a problem. I, for one, am glad that the web continues to evolve beyond its original design, clearly that's not something you're as interested in, both viewpoints are valid.

<comment><USER19> So my point here isn't that I feel those features are superfluous, but that that including them wholesale into the web browsing application directly is bloat -- it would be better served to produce separate applications specialized for those features.

Bookmarks, for instance, can be handled in a much cleaner and portable way than isolating them to the specific browser implementation. The same can be said for history, authentication, and so on.

Also, to be fair, I wasn't arguing for minimal codebases -- that was your point. I was providing examples for the GP.

<comment><USER15> And this is where I'm bored with bloat rants. "Software X is bloated! <lists 5 common features everybody uses daily>"

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER28> "There are very little tools available to to help the user select unbloated software"

Actually there is a whole community around this [http://suckless.org/](http://suckless.org/)

<comment><USER29> It's a funny idea of sucking less where any user configuration involves editing config.h and recompiling.

<comment><USER30> Which is easier? Re-running make, or having to write and induce another library to read configuration files?

Configuration files introduce a new point of failure (file not present, file corrupted, file not readable), a point of slowdown (how long does it take to read the file from disk, how long does it take to parse and load the file), and a point of complexity (parsing even ini files is pretty complicated, if you want to support the myriad of ways we write them).

All of this for values which change once every... how long? Once a year? Once an install? Or for most configuration values, never?

I still use configuration files, because I'm OK with including third party libraries... but I can certainly understand why some people may not be.

<comment><USER29> > Which is easier? Re-running make, or having to write and induce another > library to read configuration files?

It's certainly easier for the programmer to just leave some of the work to the compiler, but it's at the cost of being a complete pain in the ass to packagers and users.

Do you even have to do much work yourself? .Xresources is already parsed and loaded for you by xrdb if you can't afford the cost of an extra 100 microseconds doing it yourself. Is the API to interact with that mindblowing horrid or something?

> All of this for values which change once every... how long?

When I'm configuring software to taste, several times a minute. And considering this is likely to be my first exposure to the software, it better not suck completely.

</comment></comment></comment></comment><comment><USER31> Software bloat as such doesn't make me sad.

Free open source software bloat makes me sad.

However, that bloat is winning on its own merits. For instance, GNU/Linux distributions which are minimal are not popular. The popular ones tend to be the bloated ones.

Vim has gotten a lot bigger in 20 years, yet I'm not going to jump ship to a smaller vi implementation.

FOSS makes us confront the fact that we actually seem to like bloat. We inflict bloat upon ourselves --- there is no monopolistic software vendor there to blame.

<comment><USER32> Because bloat is like government. Multiple people might agree that there's too much of it, but they don't necessarily agree on which parts should be gotten rid of.

<comment><USER33> This. As always, there's a relevant xkcd[1]. Features that I might decry as bloat are probably someone else's "necessary, to be preserved at all costs" features. If you want to cover a large number of use cases, you have to include all of them. And with that comes bloat. There's a reason why even a minimalist CLI-only Linux installation requires more than 24MB of RAM when Windows 3.1 runs on 3MB - the Linux kernel is capable of a hell of a lot more.

[1][https://xkcd.com/1172/](https://xkcd.com/1172/)

<comment><USER31> A minimalist CLI-only Linux installation was still possible in around in 2 megs of RAM in 1994.

A minimalist XWindow installation was possible with a 40 megabyte hard drive and 4 megs of RAM over a 386 CPU. (That's similar specs to what 68K-based Sun workstations had perhaps a decade before that.)

</comment></comment></comment></comment><comment><USER34> Related: great article on code inflation [https://www.computer.org/cms/Computer.org/ComputingNow/issue...](https://www.computer.org/cms/Computer.org/ComputingNow/issues/2015/04/mso2015020010.pdf)

</comment><comment><USER35> The bloat is simply a side effect of the evolution. Software is not as much designed as evolved.

You make a name for yourself in SW development by adding features that others deem useful. You get money (in commercial setting) or prestige (in freely distributed software) if you seem to be producing something useful. It's trivially easy to recognize a contribution that adds code, but it's hard to recognize a contribution that means absence of something (e.g. absence of bloat, absence of memory hogging, ...). You get inclusion in newer, larger or more important projects easier the more you make yourself recognized.

So any useful software gains more contributors that add things than those who remove things. Commercial code can and does gain developers if it earns money, open source software gains developers if it is deemed useful by programmers.

This is a force that shapes both the group of involved developers and the resulting software in a process akin to evolution. In both cases the selection is biased towards adders of code. There's also always possible to add improvements that help some use cases and audiences. On the other hand, arguing for removing something or limiting might make you unpopular (you are seen as an obstacle to everlasting progress) and removed from the group of developers. Rare people have enough recognition and clout to prevent inclusion of something (Linus Torvalds is one of them - he can get away with rejecting patches to Linux kernel and he can play the role of the kernel guardian).

On the whole, software expands until it fills the resources available.

</comment><comment><USER36> That's pretty much the only reason I cringe every time somebody writes a piece of client code in golang.

While I really like the language itself, statically linking everything is creating exactly what this article describes.

Burn karma, burn. I don't care.

<comment> vezzy-fnord Not gonna burn your karma, however:

a) You are failing to account for the bloat caused by the presence of the dynamic linker, the dynamic loader, all the code that must operate under the assumptions of a dynamically linked environment, and the various auxiliaries used to treat shared library hell issues like WinSxS and libtool.

b) Most modern static linking implementations do things like sharing of text segments across processes and other dedup techniques, so they're not actually that bloated at all.

<comment><USER36> So maybe my comment stems from ignorance.

Are you saying that two Golang projects sharing the same (large, for the sake of the argument) dependency would not take (size of the dependency * 2) on i.e. the Ubuntu live CD (as was the example in the fine article)?

<comment><USER37> Correct.

I would not be surprised if those two Golang projects take _less_ than the size of the dependency. 2x is a degenerate worst-case.

With static linking, you only need to pull in things you actually need (and you can optimize from there!), whereas with dynamic linking you need to pull in the entire dependency regardless. (You only need to pull in one copy regardless of how many things are using the library, true. But you need to pull in one full copy always.)

There are _very_ few cases where you actually use the entire library in a project - and if you are indeed using an entire library in a project your project is necessarily large enough compared to the library that it's not much overhead percentage-wise.

<comment><USER36> That makes a lot of sense.

Thanks for the insight, I now understand why my comment was misguided.

</comment></comment></comment></comment></comment><comment><USER38> point 2 about atom:

Well, writing a text editor is far more complicated than it seems at first place.In order to support big files (50mb logs for instance), you need to make all your code rely on complex memory management, streaming and caching. Maybe js is not the right tool for the job in order to implement these features. I always thought that atom should be build in Qt with an api that can interact with JS,a bit like Adobe products for instance. That way you still allow JS plugins, just like Photoshop while getting a max of perfs thanks to C++.

<comment><USER39> Atom is a super weird example, wouldn't it bloat the software to add support for files larger than 2MB? Wouldn't that be feature bloat? I mean, a code editor shouldn't have to deal with gigantic files since code shouldn't be written that way <sup>[citation needed]</sup>.

<comment><USER40> What if the code isn't written but generated? How would I inspect it with me editor?

</comment></comment></comment><comment><USER41> Only experience with the same problem space can make you accurately predict where a bottleneck is going to be. Premature optimization will have you focusing on areas where optimization isn't required. YAGNI applies to all levels of development.

I would rather see bloat and new ideas, than only experts working in a problem domain. My best ideas come from a marriage of understanding a single problem space, and a wonder what I can do in another. Bring on the bloat.

</comment><comment><USER42> Feature bloat is inevitable if you write an application in which thousands of users want different features. Most users want just a subset of the features, and think of the rest as "bloat" even though it might be a core feature for another user. The alternative is multiple lighter applications which would just reduce bloat at the cost of integration, a trade off almost no one seems to want.

<comment><USER37> Or, you write the application as a plugin-centric architecture with very minimal core features, and go from there.

Not perfect (especially as writing things as plugins tend to introduce a certain amount of bloat regardless), but it can be better regardless.

</comment></comment><comment><USER43> I guess devs don't necessarily believe that the bloated software is good. However, they believe that the project should be developed forever, which yields the same result. I've written about it here: [http://250bpm.com/blog:50](http://250bpm.com/blog:50)

</comment><comment><USER44> The notion of 'premature optimisation is evil' is partly to blame; It's not a terrible rule, but it's much better with conditions applied. i.e. apply some intelligence/judgement to where you use optimisation rather than just lazily following some rule.

<comment><USER31> Firstly, lack of optimization for software size or execution time _is_ a form of optimization: it's optimization of someone's time.

Not writing a compiler for your scripting language saves you years.

Not choosing carefully what features to include in a program, or what packages in a system image: design time saved again.

It also saves considerable time if a user wants the program to do something, and by golly, "look, they thought of that already: there is a feature for it!" Seconds later, the user is just doing whatever they need instead of surfing the web for workarounds or calling support.

Having all the features also increases the flexibility of customization: you have more choices about what you can remove to create smaller images which have specific feature sets. You can hardly remove anything from a minimal image to make a specialized custom image.

I.e. by not making a program as minimal as possible, compact as possible or fast as possible, you _are_ making some kind of trade off. Though the program is worse in some regard, there exist parameters (of something, not necessarily the program) which have gotten better: if you think about it a little, you can identify what those parameters are. The worsening in some of those parameters in a "bad trade" is what makes premature optimization "evil".

<comment><USER44> I agree with the general point, however, I believe it's commonplace for software to be poor on those other metrics you mention too, i.e. the one metric that /has/ been optimised is development cost. All of the optimal outcomes define a Pareto front, i.e. spend time optimising feature A versus speed, cost, etc. But as soon as you bring in low(er) quality engineers you're moving away from the Parento front, probably quite significantly so.

<comment><USER31> I.e. not only will there be bloat, but users won't find the features they need, it will be delivered late, and with bugs, etc. :)

</comment></comment></comment></comment><comment><USER45> I don't care if an app is 20% bigger in file size as long as the user interface makes sense and the product actually works, especially if the bloat is due to a programming language or architecture that makes it easier to add new features or fix bugs.

<comment><USER21> But what if it's 200% bigger? I remember reading an article that looked at the time it takes to load MS office under Windows. Even though computers over the last 15-20 years or so are much, much faster, the wall-clock time to get Word or Excel up and running has pretty much stayed constant. Granted, disks haven't kept pace with CPUs, but when your computer is 100 times faster and it still takes just as long... Is that a good trade off?

</comment></comment><comment><USER44> I've idly thought of writing a 'manifesto for quality software', and/or trying to start some kind of political-esque movement to that effect.

I get annoyed by having to reboot my TV or radio when they freeze up, or by having delays to my channel changes, or having to navigate complex menus to do things that would have just been a physical button click before.

(this is all part of the same problem as bloat IMO).

This is where the likes of Apple or Dyson do well (or OK) I think. It's not necessarily that they're brilliant at what they do, it's just that the competition is pretty awful.

</comment><comment><USER46> this discussion reminds me of... [http://s1.postimg.org/6tm9yeue7/invisible_software.jpg](http://s1.postimg.org/6tm9yeue7/invisible_software.jpg)

</comment><comment><USER47> Lotus 1-2-3 is the textbook example of the benefits and costs of the speed / feature trade-off curve.

A major reason for 1-2-3 becoming dominant was its speed and memory efficiency; it was written in assembler. If you had a 640K machine, 1-2-3 let you write bigger spreadsheets than anybody else could.

But 1-2-3 was killed by Excel because it lost the feature race. It's origins in assembly language gave it a significant disadvantage in this race.

<comment><USER48> > But 1-2-3 was killed by Excel because it lost the feature race. It's origins > in assembly language gave it a significant disadvantage in this race.

Yet the winner was written in C++ for many years, while the world was distracted with the less inefficient VB.

Now some parts are .Net, but the crucial parts are still C++.

</comment></comment><comment><USER49> You are not alone. See, for example, suckless.org.

</comment><comment><USER50> Atom and Vim (and imo even Ubuntu) aren't good example of software bloat. While they might be slow and use a lot of memory, they're usually shipped with basic functionality and more functions can be added and removed at any time. Good examples are iTunes, Office, iOS and Android (the latter two are usually shipped with non removable bloatware).

<comment><USER30> In my (controversial) opinion, Atom is a great example. It includes/requires Nodejs, an embedded web browser, and runs Javascript, to run a rather basic text editor.

And in many cases, it's slow, CPU hungry, and memory intensive. Those three characteristics are the very definition of bloat to me.

<comment><USER50> I don't think Atom wants to be a basic text editor in the first place. It's shipped as a basic editor but the killer feature is that you can easily hack together extensions to suit your needs. It's a tradeoff: you pay for the html+js engine, but get a lot of potential developers. That being said, having worked with Atom on a larger project I can't confirm it's slow.

</comment></comment></comment><comment><USER51> Atom is designed to harness community participation from a community that currently embraces some technology that can easily lead to bloat.

So ti's a tradeoff. On the margin, many more people are likely to write a halfway decent Atom extension than learn elisp and write one for emacs.

</comment><comment><USER52> There is a nice study in the subject:

[https://twitter.com/lix/status/589171043010412544/photo/1](https://twitter.com/lix/status/589171043010412544/photo/1)

</comment><comment><USER53> I think lots of the bloat is actually cruft that piles up over the years. Why can't we remove it? Because somebody will use the feature and complain about it getting removed.

</comment><comment><USER54> "In fact, in my experience the process of finding such bottlenecks on running systems is itself quite time-consuming - time which cannot be spent actually reducing bloat."

Wow. Talk about a self-refuting argument. If it's hard to figure out where to optimize a RUNNING system, how is it supposed to be _easier_ to do so when the system is being created?

Arguing "bloat" is "bad for performance"? No problem - graphs or GTFO. Otherwise all you're left with is the emotional "OMG NUMBERS ARE HIGHER NAOW THAN BEFORE" drivel.

</comment><comment><USER55> A blog that has a full screen image, with no text and adds no value to the story asks why there is software bloat?

</comment><comment><USER56> Over time, all software tends to get bigger and not necessarily better.

Windows went from 7MB required (95) to 6GB required (Vista), 1000x bigger, in just 10 years. It's true in file formats as well and verbosity is one of the reasons XML was/is so hated.

There is an irresitable urge to make things bigger bigger bigger, and huge cpu, mem, and disk resources are essentially free.

</comment><comment><USER57> We can't all agree on the definition of 'software bloat'.

Is using more memory resources for caching "bloat"? It irks me when someone pulls a task manager screenshot, orders by memory usage, and picks one application out of it. "See, program X is using XXXMBs of memory! Bloated!" Well, perhaps it is, perhaps it isn't. You are still using it, so it is probably doing its job well. Perhaps that "wasted" memory is being used for caching.

This is specially true when people compare OS memory consumption. If an OS is not using all your memory, you are wasting it. It should be using it for _something_ , be it caching, eager loading, whatever. As long as you can quickly reclaim it when needed.

Same goes for CPU usage. "It's using 100% of my CPU!". Well, did you tell it do anything? If so, isn't that what you want? You want the task to complete quickly so it can go back to idle. Now, if it is supposed to be idling, and using a lot of CPU, that's a problem (Slack, I'm looking at you).

From the article:

> The same CD that hasn't been able to fit Ubuntu since 2011 still fits > approximately 150,000 pages of unformatted English text without any > compression.

Well, yeah. But one-dimensional metrics are useless. What about the number of packages? Did it increase? Is Ubuntu now packing high-resolution artwork, to be used with our 5k displays? What else has changed? I'm certain that the CD is not all source code, so the English text comparison is meaningless.

>The burden of selecting software that is not bloated is entirely on the user. The default is bloated, if you want the unbloated version, you'll have to work (search) for it yourself. And in many cases (e.g. anything that needs a web browser) such a search may not even be fruitful.

Sometimes, the opposite is true. Take Vim and Atom, which are mentioned in the article. You can _add_ packages to them, so increasing the perceived "bloat" is entirely up to the user. Unless the user takes the easy way and installs a "vim-full" package. Which, if we have memory and cpu to spare, isn't usually a problem. We are talking about VIM in the age of laptops with 16GB of RAM.

> There are very little tools available to to help the user select unbloated > software. Very few packages make any claims about their storage and runtime > charactaristics at all

Now, here I agree. It is something difficult to measure.

> Over time, the battle against bloat is always lost. Even Ubuntu, which has > traditionally presented itself (besides other things) as a method to extract > a few extra life-years out of old hardware, is mentioned in the list above. > In other words: it's only less bloated than the alternatives.

Yes. And yet it is inching closer and closer of being "ready for the desktop". It has to cater to a lot of people, which means bundling lots of features. Still less "bloated" than other commercial operating systems. Considering the number of available packages, Ubuntu offers a very good deal.

> or even simply the introduction of flash screens.

Oh, now we are in agreement. See, if you are waiting for a splash screen, you can't do your job. The software is not doing its job. Therefore, the amount of time being spent at the splash screen should be reduced, so that we can eliminate the need for one. In the bargain, eliminating the code and artwork for the splash screen, thus reducing bloat.

Still, in some cases, this is unavoidable. Take games. They will often present splash screens when loading a level (if they have such a concept). Some of them will even go as far as present animated 3D geometry, using the GPU (and CPU). Which are mostly idle anyway, waiting for I/O. Sometimes, one can devise a better way of packing the files, to reduce loading times. Even more so when the actual serialization mechanism is inefficient(hi, Kerbal Space Program). But what they are usually trading off is a lag-free game play, in exchange of a loading screen (think of it as warming a huge cache). Is that bloat? The assets are huge, because we want them to be.

Are you developing for an embedded platform? No, mobile doesn't count, they are effectively shrinked PCs from a few years ago (with non-mechanical storage even). If so, then worry about every CPU cycle you are using, as well as storage. Build your own linux distribution if you have to, compile with the exact flags for your platform so you can generate optimal code.

Running in a battery powered device (no matter the size)? Then try not to use too much CPU, and certainly not constantly. Batch stuff, run in bursts, get it over quickly. Disable any non-essential tasks.

Is a background task? Try not to disturb the rest of the system, please.

A foreground, interactive desktop application? You are likely the focus of the user's attention, do whatever it takes to minimize the latency! The only reason not to gobble all RAM is that the user may be running other stuff too. And the reason for minimizing CPU usage is heat and power. Other than that, I bet a user will rather have an application that is making use of all resources available, if it means getting work done quickly. And feeling... "snappy"!

If the user is not being impacted, then I don't see the problem. My issue with Slack, for instance, is that it uses a lot of system resources _and_ doesn't feel fast in return.</comment>


DragonFly BSD 5.2 - <AUTHOR> https://www.dragonflybsd.org/release52/ <comment><USER2> Just the other day I voiced [1] a concern on a ZFS thread about not enough modern filesystems [2] shipping as defaults (or being recommended as such), despite some of these filesystems having been around for many years.

This is a promising move to the contrary.

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

[2] in some loose, but recognizable definition of modern, featuring checksumming, CoW, deduplication, snapshots...

<comment><USER3> In some ways I think we actually need simpler file systems more than fancier ones. Here's an exercise: create a USB flash drive that can be both read and written on any system it is plugged into, by any user, without using FAT.

Can't be done. It's 2018 and FAT is still apparently the best we can do for universally usable filesystem.

And don't go trying to pin this on Windows not supporting ext or something stupid like that, because an ext filesystem cannot by default be both read and written universally even on systems that have full ext support, because they bake in permissions and the default umask botches this simple use case.

I realize this is sort of tangential to what you're saying, but I think a big problem we have in tech communities is that we focus too much on fancy interesting things and not enough on stuff that gets things done simply.

<comment><USER4> Have you tried UDF?

[http://duncanlock.net/blog/2013/05/13/using-udf-as-an- improv...](http://duncanlock.net/blog/2013/05/13/using-udf-as-an-improved- filesystem-for-usb-flash-drives/)

<comment><USER3> UDF has a lot of issues in actual implementation. For instance MacOS will only support UDF on an unpartitioned disk, while Windows will only support it on a partitioned one (IIRC was true for 7, may not be anymore). Additionally, since it has posix permissions, I expect it will have the same multi-user issue on posix systems that ext does, though I haven't tested this.

</comment></comment></comment></comment><comment><USER5> With DragonFly's architecture being designed with multiprocessing and clustering in mind, how does it fare (relative to Linux and other BSDs) in modern environments with many-core CPUs, horizontally-scalable architectures, reliance on VM-based workloads, and containerization?

I would think it would really shine, but haven't seen comparisons - or much market uptake.

Wouldn't significant advantages result in lower costs (e.g., fewer CPUs needed because of higher performance per core due to lower OS overhead) and therefore economics would drive greater use? If it hasn't, why not?

<comment><USER6> I'm not an expert on DragonFly, but from what I know it's design differences aren't really that radical. It differs substantially from FreeBSD, but it's not like a fundamental re-imagining optimized for SMP. Performance is a bit better in some places, and about the same in others.

I do think DragonFly is neat and quite interesting, but I suspect it didn't gain as much momentum because the community behind BSD is already small and reluctant to fracture without stronger reasons. It's worth noting that this is not like spinning off a new Linux distro where you're ultimately just repackaging different variations of the same basic OS - DragonFly is effectively an entirely different OS since the kernel is significantly different.

Slightly out of date, but still relevant benchmarks: [https://www.phoronix.com/scan.php?page=article&item=freebsd1...](https://www.phoronix.com/scan.php?page=article&item=freebsd11-beta- benchmarks&num=1)

<comment><USER5> Thanks, I took a look through that and most (all?) of the benchmarks seemed to be fairly traditional tasks, some not even highly threaded.

I guess I'm wondering if complex, multi-box, cloud-scale workloads have any advantage on Dragonfly - or if the optimizations for clustering are in such a narrow band of use cases that modern architectures have passed it by just through brute force.

There's an irony here, in that Matt Dillon was an ex-Amiga hacker (IIRC, some of Dragonfly's architectural choices were inspired by the Amiga). Anyway, the Amiga's linear memory, co-processor-driven architecture was ridiculously more elegant than the PC's segmented memory, CPU-bound approach. Didn't matter though, a huge investment in working around the PC's limitations led to its market dominance.

So, if massive technical accommodations for less efficient OS architectures end up marginalizing Dragonfly, it would be a bit of history repeating itself.

And I'm sure the irony wouldn't be lost on Mr. Dillon.

</comment></comment></comment><comment><USER7> I never heard of HAMMER2( or HAMMER) until just now, but a quick search seems awesome. I might have to give bsd another try, its been over a decade.

</comment><comment><USER8> Anyone know what the state of GPU support actually is? The Supported Hardware page [1] only says "Intel GPUs are supported up to the Skylake generation (2016 machines)", but this seems to be outdated. At the very least, Matt Dillon himself reported good OpenGL performance with a Kaby Lake machine [2].

[1] [https://www.dragonflybsd.org/docs/supportedhardware/](https://www.dragonflybsd.org/docs/supportedhardware/)

[2] [http://lists.dragonflybsd.org/pipermail/users/2017-September...](http://lists.dragonflybsd.org/pipermail/users/2017-September/313586.html)

<comment><USER9> DragonFly web documentation is wiki-based and tends to not always be up-to- date (contrary to man pages).

All recent Intel GPUs are supported, including Kabylake and Coffeelake.

</comment></comment><comment><USER10> A few years ago I wanted to try this as a local Minecraft server but it was 64 bit only and the spare machine I had was 32 bit. Glad this post came up because now I've got a 64 bit machine sitting in my basement I had forgotten about until now.

<comment><USER11> Can you not just spin up a cloud instance and boot it off of a cd image?

</comment></comment><comment><USER12> Are there any plans to bring HAMMER2 in to Linux?

<comment><USER13> Afaik the whole purpose of DragonflyBSD is HAMMER so no.

<comment><USER14> Can you go into more detail please? That sounds interesting. I thought it had to do with concurrency.

<comment><USER15> You're not wrong. Interview from 2004 [0]: "DragonFly split off from FreeBSD-5 over major architectural differences, not anything else. We really do feel that FreeBSD-5 is taking the wrong approach to _SMP_ and building something that is so complex that it will ultimately not be maintainable. We think we have a better way."

But their original architectural decisions were done with this goal in mind [1]: "The ultimate goal of the DragonFly project at its inception was to provide native clustering support in the kernel. This type of functionality requires a sophisticated cache management framework for filesystem namespaces, file spaces and VM spaces." It's not difficult to see how HAMMER came to be three to four years later, given their stated design goals.

[0] [http://www.onlamp.com/pub/a/bsd/2004/07/08/dragonfly_bsd_int...](http://www.onlamp.com/pub/a/bsd/2004/07/08/dragonfly_bsd_interview.html) [1] [https://www.dragonflybsd.org/history/](https://www.dragonflybsd.org/history/)

</comment></comment></comment></comment><comment><USER14> Are there many users of dragon fly bsd? Are people using it in production, and why/why not?

</comment><comment><USER16> Still haven't quite managed to get Dragonfly going in Azure, but not given up on it either

</comment><comment><USER17> MD5 release checksums? c'mon folks, get with the times...

<comment><USER18> I generated them; what would you prefer, and why?

I know MD5 hash collisions are vaguely possible, but I would think they would be extremely unlikely here.

<comment><USER17> There's no vague about it. MD5 collisions have been possible to generate for over a decade now.

[http://www.win.tue.nl/hashclash/SoftIntCodeSign/](http://www.win.tue.nl/hashclash/SoftIntCodeSign/)

A sha256 or sha512 would be more appropriate.

<comment><USER19> If you don't trust the dragonfly team to not produce collisions, you probably shouldn't use the software anyway.

<comment><USER20> The malicious case would be a bad actor distributing phony files that appear to check out because the flaws have been found that would allow someone to do so.

<comment><USER21> In practice today this requires that the bad actor collaborates with the real distributor.

MD5 fails to _collision_. A collision is when you can find two different things with the same hash. But being able to collide the hash is NOT the same as being able to find a second pre-image, which is what you'd need in order to get "phony files that appear to check out" if the person who originally issued the MD5 checksums didn't collaborate with you.

<comment><USER22> There have been practical demonstrations of using padding in several formats to generate valid files that collision with an original one, but with entirely different contents.

This means that it is possible that someone could download the real image, introduce some rootkit, and then tinker that (for instance, by adding a hidden file with carefuly crafted content) until the resulting md5 is the same as that of the original image. Then hack the server and upload the modified image in place of the original one, and everyone who installs Dragonfly is now their minion.

If you use a stronger hash (which is not harder for anyone than using md5), then this attack vector becomes impossible. So... even if it is a remote possibility, just use the stronger hash because it is just a dominant strategy (it has upsides, yet 0 downsides).

<comment><USER23> There have been no practical demonstrations of colliding the MD5 of an arbitrary file (ie. pre-image attack), only situations where two files are created specifically with the intended purpose of creating a collision. This is precisely what the post you replied to said but you seem to have not understood that there's a distinction.

Yes, it is possible that the DragonFly developers could collude to create two ISOs with the same MD5, one good and one malicious. No, it is not possible that random, evil ne'erdowells could replace the ISO with one with the same MD5, unless the DragonFly developers have conspired with them to make that possible.

If you don't trust the DragonFly developers not to collide the MD5s, you probably shouldn't trust them with the code running in your kernel anyway.</comment></comment></comment></comment></comment></comment></comment></comment>


How two students built an A-bomb (2003) - <AUTHOR> http://www.guardian.co.uk/world/2003/jun/24/usa.science

<comment><USER2> Google John Aristotle Phillips.

He was a princeton student in the 70s who designed a nuclear bomb as a junior paper, and built a rather realistic mockup in his dorm. It was published and placed in the library alongside the other junior papers, until the FBI came and confiscated it.

<http://europeancourier.org/terrorism_05_21_2006.htm>

<comment><USER3> _John Aristotle Phillips ... designed a nuclear bomb as a junior paper._

No. <http://www.phyast.pitt.edu/~blc/book/chapter13.html#4>

_The effort by the Princeton student, John Phillips, was much more widely publicized. He made extravagant claims that his bomb would explode with a force of more than 10,000 tons of TNT. He took on a publicity agent, wrote a book, appeared on many TV and radio shows, received very wide newspaper coverage, and even ran for Congress.

What he claimed to have produced was a design for a bomb in a term paper prepared for a physics course. I spoke to his professor in that course, who said that there was nothing in his paper that would ordinarily be called a design. There were only crude sketches without dimensions. There were no calculations to support his claim that his bomb would work. He had collected a lot of information that would be useful in designing a bomb, for which the professor gave him an A grade.

Phillips was being called by media people so frequently that he had to have a separate telephone installed in his dormitory for that purpose. His professor told me that he himself had been contacted by many newsmen, but they never printed what he told them — they only trumpeted that Phillips had designed a workable bomb.

Several people have told me that professional government bomb designers have said that a design for a bomb by some student would work. I know that this could not be true because it would be a very serious breach of security regulations for a person who was ever involved with the government program to comment on a design that is available to the public. Note that the MIT student's design was judged by a "Swedish expert." With regard to such claims about Phillips' design, no professional could possibly consider a sketch without dimensions to be a design capable of being evaluated for performance. Science and technology are highly quantitative disciplines, but apparently Phillips does not understand that fact.

There have been numerous statements in newspapers, including our university paper, that any college student could design a nuclear bomb. In reply, I published an offer in our university paper of an unqualified A grade in both of the two courses on nuclear energy that I was teaching for any student who can show me a sketch of a workable plutonium bomb together with a quantitative calculation showing that it would work. My offer has been repeated about 10 times over the last 15 years. Three students turned in papers, but none of them had as much as 5% of what could be called a design.

All of this discussion has been about designs on paper, but as is clear from the above quoted statements by experts, that is only a small part of the task faced by terrorists. The fabrication requires a wide degree of expertise and experience in technical areas. It requires people capable of carrying out complex physics and engineering computations, handling hazardous materials, arranging electronically for a hundred or so triggers to fire simultaneously within much less than a millionth of a second, accurately shaping explosive charges, attaching them precisely and connecting the triggers to them, and so on. Where would terrorists find this expertise?_

<comment><USER2> I apologize. Its a bit of a campus legend, and as such tends to grow in the telling.

I was aware that it had been partially debunked, but I was not sure to what extent. Thank you for the clarification.

</comment></comment></comment><comment><USER4> Very interesting. It's long been said that getting the material was by far the hardest part. I guess this gives the exact date for when that was determined.

<comment><USER5> I've read somewhere that you can get a very low-yield explosion by just dropping a big enough chunk of weapons-grade fissionable material onto another one. You only get several hundred tons of TNT equivalent of explosive force, but lots of radiation. It would make the perfect terror weapon.

<comment><USER3> You either read or remembered wrong, or that source was referring to something like an explosives-grade uranium dart being dropped through one or more explosives-grade uranium donuts and from a great height. That method would not work for plutonium, which -- because of its greater propensity to prematurely generate neutrons -- requires the more-rapid mass-assembly method of an implosion.

<comment><USER5> Ah, I remembered, but not specifically enough. It was Uranium, but I forgot that it had to be darts through a donut, and I didn't know it had to be a great height.

Is that 2 stories? 10 stories?

</comment></comment></comment></comment><comment><USER6> _"... Today, the fear is back: with al-Qaida resurgent, North Korea out of control, and nuclear rumours emanating from any number of "rogue states", we cling, at least, to the belief that not just anyone could figure out how to make an atom bomb ..."_

Interesting read. A greater threat today is multiple detonation of car bombs. Easier to build & deploy ~ [http://www.walrusmagazine.com/articles/2008.09-lebanon- shia-...](http://www.walrusmagazine.com/articles/2008.09-lebanon-shia-sunni- car-bombers-interview-robert-baer-syriana-chris-watt/)

</comment><comment><USER7> My dad is a nuke engineer (studied under Rickover) who hires bomb designers -- he maintains that the physics behind building a bomb is simple and easy, and far from classified. What distinguishes the really scary weapons from home- brew isn't the science behind it, but all the engineering tweaks that optimize the results. Given his background and Q clearance in DOE, even if he wasn't my dad, I'd be inclined to believe him....

</comment><comment><USER8> _"They wanted me to build them a bomb, so I took their plutonium and in turn, gave them a shiny bomb-casing full of used pinball machine parts!"_

<comment><USER9> classic.

</comment></comment><comment><USER10> Isn't it possible for people who want the bomb to kidnap people like this? Unlikely, but possible?

Maybe it was a bad idea to declassify what they did in their lives, I mean in the interest of their security and all...or at least until they were dead!

<comment><USER11> The entire point of this story is that you don't have to be Einstein to build a nuke. Even in the 60's there was enough publicly available information that anyone with an advanced knowledge of Physics could do it. Imagine how much easier it must be now.

On the other hand, we should be worried that someone will kidnap some Plutonium. That it is difficult to get is the only thing saving us. Not very comforting.

<comment><USER3> _we should be worried that someone will kidnap some Plutonium._

Why steal it, when it is so easy to make?

 _it is difficult to get_

Plutonium (even explosives-grade) is not difficult to get. All one needs is a uranium-fueled research reactor.

<http://www.phyast.pitt.edu/~blc/book/chapter13.html#4>

 _Another alternative would be to use a research reactor, designed to provide radiation for research applications rather than to generate electricity. At least 45 nations now have research reactors, and in at least 25 of these there is a capability of producing enough plutonium to make one or more bombs every 2 years. Research reactors are usually designed with lots of flexibility and space, so it would not be difficult to use them for plutonium production.

A plant for generating nuclear electricity is by necessity large and highly complex, with most of the size and complexity due to reactor operation at a very high temperature and pressure, the production and handling of steam, and the equipment for generation and distribution of electricity. It would be impossible to keep construction or operation of such a plant secret. Moreover, only a very few of the most technologically advanced nations are capable of constructing one. No nation with this capability would provide one for a foreign country without requiring elaborate international inspection to assure that its plutonium is not misused. A production or research reactor, on the other hand, can be small and unobtrusive. It has no high pressure or temperature, no steam, and no electricity generation or distribution equipment. Almost any nation has, or could easily acquire, the capability of constructing one, and it probably could carry out the entire project in secret. There would be no compulsion to submit to outside inspection._

However, making a plutonium-based explosive is difficult (from the same link):

 _The fabrication requires a wide degree of expertise and experience in technical areas. It requires people capable of carrying out complex physics and engineering computations, handling hazardous materials, arranging electronically for a hundred or so triggers to fire simultaneously within much less than a millionth of a second, accurately shaping explosive charges, attaching them precisely and connecting the triggers to them, and so on. Where would terrorists find this expertise?

Experienced and talented scientists and technicians generally enjoy well-paid and comfortable positions in our society and hence are not likely to be inclined toward antisocial activity. Recruiting would have to be done under strictest secrecy, which would have to be maintained over the development period of many weeks. Even one unsuccessful recruiting attempt could blow their operation. Moreover, a participant would face a high risk of being killed in this work. And if the plot were discovered he would face imprisonment, not to mention an end to a promising career. Terrorists would surely face severe difficulty in obtaining the needed expertise._</comment></comment></comment>


Ask HN: Am I working enough? - <AUTHOR> I've recently seen a few HN posts/read a few blogs/heard a few interviews where someone mentions they are working 60+ hours per week (or at least how they were doing that when they launched their start up) to drive their careers forward. On the other hand you always hear people from the Four Hour Work Week or 37Signals camps saying how you should hyper focus and get a ton done in a super small number of hours.
I'm no good at either of those.  I love everything that I am doing right now, and am incredibly passionate about it. That said, I tend to work about 40-45 hours week on the following:
12-15 hours contract work (usually putting together basic marketing sites for small businesses).
12-20 hours a week working on two of my own projects.
8-10 hours studying Ruby on Rails and improving my general technical skills (although obviously this one spills over into the other two quite a bit).
I have some hyper focused periods where I get quite a bit done in short periods of time. I have other times when I get very little done.  In general I think I average out to being a bit more productive than most people (though everyone says that about themselves so don't necessarily believe me).
In general I find myself a bit disappointed at how much progress I am making, both on monetizing my own projects and improving my coding skills. I wonder if I am working enough hours (or at least enough SUPER-focused hours) to achieve my goals?
Is this something where I need to start putting in more time, or is this something where I should say to myself "OK, this will take me 5-10 years to be where I want to be, just take it easy, don't burn out and you'll be fine."?
Any thoughts, bits o' wisdom, or semi-coherent ramblings will be accepted.  Thanks!
EDIT: I should mention that my background is in Biochemistry, and that I have only been working on web stuff for the last two years or so. <comment><USER2> Whether or not you're working enough isn't necessarily directly related to how many hours you work. The only question you need to answer is: "Am I on track to achieve my goals, in the time period I want, working as much as I am?"

And even if the answer to that is "no," the solution may not be to work more hours. It may be that you need to find something more productive to do with the hours you do work.

If, as you say, you're disappointed about the progress you're making, you really need to figure out if that disappointment is just because you (possibly unreasonably) feel like you should be progressing faster, or if you actually could be -- and actually care to be -- progressing faster.

Unfortunately I don't think this is a question anyone can answer for you.

</comment><comment><USER3> This is going to sound like a cop-out, but the answer really is 'whatever works for you'. Don't measure yourself by how other people get through their day and how they make a go of it, this race is not with others, it's with yourself.

Set your goals, lay your plans and go about execution at a pace that you are comfortable with and that you feel that you can keep up for a long long time. As DanielBMarkham wrote in some other thread, this is a marathon, not a sprint so pace yourself accordingly.

</comment><comment><USER4> First question anyone should ask themselves when wondering how many hours to work are: Are you happy? If you're working 4 hours a week and you're happy, then don't change a thing.

Being that you said that you find yourself disappointed by your progress, then it's time to do something. I'm not a big fan of working for the sake of work, so I would recommend not increasing your hours, but finding out why you're not achieving the "super-focus" that you think you're missing. Do you "work" yet surf Hacker News half the time? Find out if there is any way to improve your working hours, not add more. That's a recipe for burnout.

</comment><comment><USER5> I think you'll find the answer to this question if you ask yourself the following: What's the amount of work required in order to get my business off the ground? You're the only one who knows the answer to this question since you're the only person who has a clear idea of your 2 side projects in details.

So to give you a more detailed answer, I'd say: 1\. figure out the amount of work required in order to realize your projects. 2\. Set a deadline and small goals in order to get where you want to be. 3\. Only then, will you know the number of hours you need to work on your projects.

Hope it helps.

</comment><comment><USER6> > 12-20 hours a week working on two of my own projects. > on monetizing my own > projects > find myself a bit disappointed at how much progress I am making

Something easy to struggle with is knowing when to let go, as counterintuitive as it seems, perhaps it's time for an entirely new project?</comment>


Estimates of the Prevalence of Underlying Conditions Among COVID-19 Patients - <AUTHOR> https://www.cdc.gov/mmwr/volumes/69/wr/mm6913e2.htm <comment><AUTHOR> OP here. If you are sick of COVID-19 stuff, I'm sorry. I found this useful for calculating the chances that zero/one/two of my partner and I are hospitalized, admitted to the ICU, or dies.

Given our underlying conditions, my rough calculations show a 6/1000 chance one of us is hospitalized, 0/1000 chance (rounded down) that both are hospitalized. Good news since we have kids.

Furthermore, a 1/1000 chance one of us is admitted to the ICU, and 0/1000 (rounded down) one or both of us dies.

Edit: Used a Monte Carlo simulation (n=10000) with a simple probability chain. Caveats and assumptions abound and YMMV, of course.</comment>


Ask HN: Best book on business ideas validation? - <AUTHOR> Is there such thing as the Bible of tech start-up/business ideas validation/discarding? <comment><USER2> Rework?</comment>


U.S. judge rejects World Chess bid to block websites from airing moves - <AUTHOR> http://www.reuters.com/article/us-chess-world-lawsuit-idUSKBN13600V <comment><USER2> Fun fact about the first game : after 1.d4 Nf6, the World Champion played 2.Bg5, which is fairly rare at top level in classical time control, and pretty much unprecedented in world championships. Why is it fun? Because this opening is known as the Trompovsky, often nicknamed the "tromp". Magnus more or less admitted that it was a wink at the newly elected US president.

</comment><comment><USER3> A lot of the comments here on copyright seem to be looking for answers to distinguish this from other copyright issues. Rather than summing up every copyright argument for or against, I thought I'd link to a fairly relevant case: Feist.

[https://en.wikipedia.org/wiki/Feist_Publications,_Inc.,_v._R...](https://en.wikipedia.org/wiki/Feist_Publications,_Inc.,_v._Rurwal_Telephone_Service_Co).

Feist is a case where a phone book company stole the data in a phone book, and began reselling it. It deals with publication of facts, and is a situation where there's a reasonable public policy argument for incentivising the private company's work collection of phone number data. It's a commonly taught fundamental Copyright claim that is a great starting point for those interested in researching further.

<comment><USER4> [https://en.wikipedia.org/wiki/National_Basketball_Ass%27n_v....](https://en.wikipedia.org/wiki/National_Basketball_Ass%27n_v._Motorola,_Inc.).

> The district court held that Motorola and STATS did not infringe NBA's > copyright because only facts from the broadcasts, not the broadcasts > themselves were transmitted. The Second Circuit Court agreed with the > district court's argument that the "[d]efendants provide purely factual > information which any patron of an NBA game could acquire from the arena > without any involvement from the director, cameramen, or others who > contribute to the originality of the broadcast" [939 F. Supp. at 1094].

<comment><USER5> I think this is a more correct case to apply.

The Feist case was about the expense accrued in aggregating the information and the incentive issues that arise if those efforts are not protected.

The NBA case was about the division of rights between the competition organizer and those attempting to report on it. Specifically, are the reporters required to delay their reporting efforts when the only information being reported generated by the event is factual.

If I understand correctly, this ruling doesn't preclude the event organizers from banning all electronic communication devices from the premises. It just prevents them from pursuing any civil penalties from those that report on the event.

<comment><USER6> I wonder what the effect on attendance would be, if major sporting events had a "no cell phones" rule. My guess offhand: it would be devastating to ticket sales.

<comment><USER5> I've been trying to mull that out as well from an economic perspective but I think it's highly dependent on the existing distribution networks which adds additional complexity.

Major League sports information is disseminated fairly quickly and the attendance levels make technological prohibitions a challenge. The nature of world chess championships make it a little different, as long as the globally recognized top ranked players are in attendance (preventing an organizational schism) I think the organizers could do whatever they want.

In the end I think this ruling just means they can't enforce a civil penalty for violation of these rules, but there's no reason they can't expel the violator from their event.

It's an interesting case.

</comment></comment></comment></comment></comment><comment><USER7> So consider this near-future scenario:

You have a soccer match in which a lot of fans show up with cameras. Either like a Go-Pro or just their phones, or like Google Glasses.

From the many fan cams, you can reconstruct the state of the match. From the FIFA video games, or from image analysis, you have all the player likenesses.

So then someone could "watch" the game from any vantage point, using just the "facts" of the game, without doing an actual re-broadcast of the game.

What then?

<comment><USER8> I'm failing to see what's wrong with this. I also don't see how an organization like the NBA or FIFA or whoever can make a claim to "own" the events of a game.

The sale of exclusivity rights seems like the scam: The premise that one can copyright an event itself and not just a particular recording of it.

If someone is there and recording I say that should be OK. If another person aggregates the views of multiple such recorders then they would need to obtain permission from each.

Reconstructing the entirety of a game with virtual players is _already_ legal and amounts to an original work. Where's the problem?

</comment></comment><comment><USER9> Apropos, to anyone who wants to watch the live moves, with expert commentary, they are here (this is the defendant from the Reuters story):

[https://chess24.com/en/read/news/chess24-win-moscow-case- ann...](https://chess24.com/en/read/news/chess24-win-moscow-case-announce-new- york-line-up)

[https://www.youtube.com/channel/UCkTCNuQ2mGfW6-SpHpaze_g](https://www.youtube.com/channel/UCkTCNuQ2mGfW6-SpHpaze_g) (direct link to livestream)

If you're looking for live computer engine lines, Steinar Gunderson offers that here, with 38 cores running Stockfish:

[http://analysis.sesse.net/](http://analysis.sesse.net/)

As well as PGN files (live-updated):

[http://pgn.sesse.net/](http://pgn.sesse.net/)

<comment> semi-extrinsic Regarding "38 cores": can anyone comment on whether that's sufficient to perfectly analyse the game in near-real-time, or is it just good enough to provide interesting analysis? I.e. would Stockfish running on 38 cores be competitive with / better than World Championship players?

<comment><USER10> modern chess programs are vastly superior to human players, regardless of one or 38 cores. stockfish has a elo rating of ~3350 (probably a little higher when running on 38 cores, not sure). carlsen has 2850. that corresponds with a 95% winning probability per game (or to be more precise: stockfish is expected to win 95% of all possible points over several chess matches)

it's hard to say if that's close to "perfect analysis", because we don't know what a perfect game will look like (chess is not a solved game). but compared to human level, one could say it's close to perfect.

<comment><USER11> I'm not saying Stockfish isn't stronger than any human player (even the world champion), but you can't compare ratings in two different systems like that. Magnus has never played a FIDE-rated game with Stockfish, nor has Stockfish played any rated games with a human opponent.

</comment></comment></comment></comment><comment><USER12> Anybody have a link to the complaint/application for a TRO? A lot of the comments here are talking about copyright law, but most protection or attempted protection of data is done with licensing agreements. I would guess FIDE could require the people viewing in person and on the FIDE website to agree to not disseminate accounts of the game as a condition of being allowed to watch. I'd be interested to learn if FIDE has actually attempted to limit it this way, or if the debate is truly over copyright issues. And also if they did ask for the TRO on licensing grounds, was it because their licensing scheme was invalid, or just because the type of harm they were likely to suffer didn't rise to the level needed to qualify for injunctive relief.

<comment><USER13> I don't have that but the judge was pretty dismissive. From chessgames.com:

In a hearing late in the day prior to the first game of the match, U.S. District Judge Victor Marrero was not persuaded that organizers of the $1 million, 12-game tournament had a legal right to block the websites from disclosing the moves until after each game.(7) Rejecting virtually every argument that World Chess asserted, he said, "I know this area of the law very well."

[http://www.chessgames.com/perl/chess.pl?tid=88069&crosstable...](http://www.chessgames.com/perl/chess.pl?tid=88069&crosstable=2)

<comment><USER14> There are also more details mentioned in this Chess.com article: [https://www.chess.com/news/carlsen-plays-white-in-round- one-...](https://www.chess.com/news/carlsen-plays-white-in-round-one-agon-s- injunction-denied-7037)

</comment></comment></comment><comment><USER15> In broadcast and print media, there are "facts" which are routinely _embargoed_ (they cannot be released before a certain date/time). Financial results from publicly-traded companies are similarly embargoed, even though they be simple facts. Why can't this mechanism be employed as a condition of being permitted to attend the event?

<comment><USER16> That is one of the mechanisms that they were relying on. Anyone attending the event and relaying moves is likely in breach of contract, and at least could be thrown out of the venue. Likewise, anyone who signed up for the official feed and then shared the moves is violating the website's terms and conditions and could get their account closed. But it only takes one anonymous user to sign up and report the moves to other sites.

<comment><USER17> Not necessarily.

Person A opens the stream on their PC.

Unknown to them, Person B watches that stream through the window of Person A's home, and broadcasts the information.

The only possible crime Person B did was invading Person A's privacy, but Person A does not sue them.

Person A acted entirely legal, so did Person B, and you still got all the facts out.

</comment></comment></comment><comment><USER18> The main difference between this and other sports/events is the moves are facts. They wouldn't be able to broadcast a live video feed. But you can copyright facts.

<comment><USER19> I agree with your conclusion but not your reasoning. (you accidentally wrote "can" for "can't" at the end though, maybe you have time to correct it.)

So this is why I don't agree with your reasoning:

The fact is that Ambirex's comment at 11:22 PM Friday, November 11, 2016 UTC began with a capital T as his first move. Though he could have left it at that and left his opponents to reply, this was not his complete comment. The fact is, for the second letter of his comment he chose an 'h'. And the fact is, for the third letter, he chose an 'e'. The fact is, for the fourth character he had a space. The fact is, for the fifth character he had an 'm'. The fact is...

And so forth. So while these are certainly facts -- still, they are quite creative facts. More creative than the work you put into beginning your comment with "the main difference".

So while I actually happen to agree with you, this idea of the moves being "facts" versus acts of creative expression is dubious -- where is the hard line that separates that from my reproducing your comment (or any other copyrighted work) by reference to facts? They are facts, true, but they are also the creative output of two masters of the field.

In general for cases like this judges try to look at the pragmatics. This is why the judge is quoted as saying "He said the public interest would be served by 'robust reporting,' and analysis of the event."

The fact that for him this includes fully reproducing all the moves (which of course seriously impacts the market of the organizers - as well as reproducing the whole of the 'creative output', rather than just excerpts - both of which are important standards in copyright) is one that I can probably agree with.

But if he felt that the actual interests in the matter were another way, you bet that he could extend copyright protection to the creative work of playing a game. After all, it is rare for any game between grandmasters today to match one from a database. When they do, it is similar to when similar melodies are created independently.

In fact, a chess game likely has waaaaaaaay more entropy (I am making quite a technical argument) than very short melodies which are clearly protected by copyright and for which many "variations" are already owned by others.

Why are the "facts" of the melody more protected?

So I don't really agree with your interpretation. A fact would be like "white won" or "black won" \-- rather than the creative output into the moves themselves. Though more creative than mere fact, I do agree with your conclusion -- for the same reasoning quoted in the article.

<comment><USER20> Why was this downvoted? I found it to be a pretty interesting perspective, although I do think the equation of letters in a sentence to moves in a chess game is pretty weak. Moves made in a chess game are events that factually happened in the past - copyrighting them would be akin to copyrighting a certain historical event, such that only a copyright holder is given privilege to state information about it. Letters, words, and sentences are in a creative space of expression that has its own rules and regulations.

<comment><USER21> It's a historical fact that "primitivesuave" wrote down the sequence of letters "Why was this downvoted? I found it to be a pretty interesting perspective...", but if I published it, I'd still be violating your copyright.

What's the difference between that and a chess game (which takes significantly more intellectual effort than a messageboard comment)

<comment><USER22> The difference is that they are playing a sports match, not writing a comment. The current score/position of the match is just a fact, not an artistic creation.

</comment></comment></comment></comment></comment><comment><USER23> There is a glaring inconsistency in this ruling when compared to the status quo for other sports. In baseball, football the Olympics etc the sponsors hold the broadcast rights and do with it as they deem fit. Why is this same right denied to the organizers of the World Chess Championship?

<comment><USER24> I think your analogy is wrong. Many websites broadcast live "play-by-play" info on MLB, NFL, NBA, and NHL games. These are typically done, for example, by showing a graphic of a strike zone and where pitches are located as they are pitched. However, the actual game audio and video is not broadcasted. I don't believe you need any sort of license to display this information (correct me here if I'm wrong).

As far as I can tell, that's what's going on here: websites want to broadcast the "play-by-play" of the chess game, but not the actual game footage. Now, the play-by-play for a chess game is more important than the play-by-play for a hockey game, so I can see why the organizers of the chess tournament aren't happy, but I think the correct decision was made here.

<comment><USER23> > I think the correct decision was made here.

No it was not. It says in the article: _Organizers ... failed to persuade a federal judge to block rival website operators from broadcasting chess moves ..._

 _The defendants also said that they would not simply be copying audiovisual content generated by World Chess, but displaying the moves on their own computerized chess board while adding commentary and analysis._

The ruling directly attacks the business model of the organizers and will thus reduce the chance of attracting sponsors in the future. Hence, it is not in the public interest.

Chess is a peculiar game in that the visual content of any broadcast ie players actually playing, is subordinate to the moves made. Nobody watches a chess game online for 5 hours for the fun of seeing the players think. That's like waiting for the paint to dry. Take away the advantage of broadcasting the moves with commentary and analysis and your advantage as a sponsor is gone. I would have thought the judge would have understood this and taken it into account.

<comment><USER25> Yeah, a business model is more important than the non-copyrightable nature of facts. Good thing the judge understood the actual law, which is not concerned with business models.

<comment><USER23> > Yeah, a business model is more important than the non-copyrightable nature > of facts.

I fail to see your point. The law should be applied with a dose of common sense. The organizers are not barring anyone from the "facts" as you put it just trying to get a lead in broadcasting. The law upholds the rights of organizers of other sports eg football and boxing based on their peculiarities and in case you are not aware is frequently biased in defense of their commercial rights (one only needs recall the absurdities surrounding the olympics).

For years, chess has suffered from crises caused by lack of sponsorship for events. If this ruling serves to deter future sponsors and leads to uncertainty or cancellation of matches (which has happened before) then what good is that?

<comment><USER26> Your argument can be summarized as that we should ignore what copyright law says because the consequence of the law is bad in this particular case for certain chess companies.

That's neither a sane or reasonable way to make legal judgments. Can you show a sound _legal_ argument why the judge's ruling was wrong?

FYI, there used to be a 'hot news' doctrine that might have protected the chess moves (and the FIDE made this their argument), but it's been largely superseded or overturned [1].

[1] [https://en.wikipedia.org/wiki/International_News_Service_v._...](https://en.wikipedia.org/wiki/International_News_Service_v._Associated_Press#.22Hot_news.22_cases)

<comment><USER25> "Hot news" is a good time to remember that copyright is shaped not only by US copyright law, but also by common law and the 1st Amendment.

</comment></comment></comment></comment></comment></comment></comment><comment><USER27> From a viewers perspective this is great. For past World Chess Championships you could watch ex pros/ high level players commentate on Youtube and Twitch.

</comment><comment><USER28> fascinating.

stats.com charges like $80k per season per sport or something like that for access to their live game data api.

world chess should take this all the way, airing the moves for free is undercutting their business model. seems like it shouldn't be legal considering chess is a sport.

<comment><USER23> Many folks here dont seem to understand this or agree.

</comment></comment><comment><USER29> This seems a strange move. I wonder how the same judge would have ruled if it was about youtubers livestreaming NFL games.</comment>


Red Digital Cinema Announces Holographic Media Machine - <AUTHOR> http://www.red.com/hydrogen <comment><USER2> a follow-up note [http://www.reduser.net/forum/showthread.php?159552-HYDROGEN-...](http://www.reduser.net/forum/showthread.php?159552-HYDROGEN- added-color)

 _The Holographic Display._

 _It is incredible. It is multi-view (4-view) as compared to stereo 3D (2-view). Watching shocked faces light up when people see it is really motivating. There is no good way to describe it until you see it. Hopefully we will get some skeptics eyes on it soon… then they can tell you._

 _Our display is technology you haven't seen before. It is not lenticular, which is inferior tech in every way, has been tried many times before and failed for good reason. (see Amazon 3D Fire, LG Optimus, etc). Lenticular display dramatically lowers resolution, cannot be turned off for standard 2D content, only works in one direction (usually landscape), has color crosstalk… to name just a few issues. My bet is that other "big" companies will try to re-package lenticular 3D displays with eye-tracking in response to our program. Don't fall for it._

and the original forum post and thread: [http://www.reduser.net/forum/showthread.php?159541-HYDROGEN](http://www.reduser.net/forum/showthread.php?159541-HYDROGEN)

<comment><USER3> Super interested to hear more details on the display tech. Although they specifically state 'not lenticular', providing a '4 way view' still seems to indicate some form of lens setup. There's a few microlens array based displays which, while definitely much better that an old school lenticular strips, are not great for detail.

</comment></comment><comment><USER4> Yeah, I'm going on a limb here and claim this is nothing but putting a bunch of buzz words in the name of some PR stunt.

You can be sure there is nothing _Holographic_ about this display at least, which makes me doubt all the other big words they trow around in the text: [https://en.wikipedia.org/wiki/Holography](https://en.wikipedia.org/wiki/Holography)

</comment><comment><USER5> Yeah no, we're gonna needs some vids of this.

</comment><comment><USER6> This is just an ad for an overpriced smartphone that comes with an app that rotates a 3d scene according to the device orientation sensor readings (like the Amazon devices that cost much less). 949 area code -- why are so many scammers in Orange County?

<comment><USER7> While I'd like more info on what exactly the device does and perhaps see a demo, Red is not a scammer.

They are an industry leader in digital cameras of which are used to film many major movies ([http://www.red.com/shot-on-red](http://www.red.com/shot-on- red))

<comment><USER8> I'm no expert, but just because it's used by professionals doesn't mean it's not a vanity brand. See Monster Cables and Beats by Dre.

<comment><USER9> It's losing some popularity now that companies like Arri are making better cameras, but that's been an industry leader for years... Any DP would be insulted by the accusation that RED is a "vanity brand."

<comment><USER7> As someone not in the industry, this is incredibly interesting to learn.

I only learned about RED after all the hype with their first digital cameras (that all the studios were helping to hype)

<comment><USER9> Yeah, their cameras have had some of the best technical specs in the entire marketplace for years. You can shoot at a wide variety of frame rates, and resolutions, it can shoot raw, or at a very high color space.

When it comes to cinematographers, the best tool is what they use. There's no choosing a camera because you look cool next to it...

Now there are cameras that have all or most of the features of RED, but more elegantly designed. The RED is kind of like a small PC that you can mount a lens to.</comment></comment></comment></comment></comment></comment>