Why You Should Use Tumbleweed - <AUTHOR> http://rootco.de/2016-03-28-why-use-tumbleweed/ <comment><USER4> "It uses openCV and a library of reference screenshots (with areas of interest selected to allow openQA to ignore things we don't care about) which we call 'needles' ..."

OpenQA is a fascinating project. The tests are written in perl and I think the OpenCV magical stuff is around the "check_screen()" function.

For example, a test for Firefox:

        x11_start_program("firefox https://html5test.com/index.html", 6, {valid => 1});

        # makes firefox as default browser

        if (check_screen('firefox_default_browser')) {
            assert_and_click 'firefox_default_browser_yes';
        }

[https://github.com/os-autoinst/os-autoinst-distri- opensuse/b...](https://github.com/os-autoinst/os-autoinst-distri- opensuse/blob/master/tests/x11/firefox.pm)

<comment><AUTHOR> check_screen is a non-fatal check, really useful for stuff like you cite in that example "tell openQA to see if something is on the screen, then react to it"

assert_screen is it's fatal cousin "make sure the screen has this needle on it, or die"

assert_and_click is it's mouse-controlling companion, "make sure the screen has this needle on it, then click on it"

[https://github.com/os- autoinst/openQA/blob/master/docs/Writi...](https://github.com/os- autoinst/openQA/blob/master/docs/WritingTests.asciidoc)

The above doc covers the basics, we also have a whole bunch of tutorials on YouTube

[https://www.youtube.com/watch?v=-fqvaSO6nKE](https://www.youtube.com/watch?v=-fqvaSO6nKE) [https://www.youtube.com/watch?v=a8LmqhwpVvg](https://www.youtube.com/watch?v=a8LmqhwpVvg) [https://www.youtube.com/watch?v=EM3XmaQXcLg](https://www.youtube.com/watch?v=EM3XmaQXcLg)

<comment><USER4> That's great!

I found the piece of code I was looking for inside "tinycv" (about OpenCV): [https://github.com/os-autoinst/os- autoinst/blob/3c2f5edda09b...](https://github.com/os-autoinst/os- autoinst/blob/3c2f5edda09bff3246f5438d47ad84123a5cf151/ppmclibs/tinycv_impl.cc#L200)

I switched to Debian from Fedora a year ago during the "freeze" in the release cycle. I wonder what is the stability level of Tumbleweed compared to a standard (non-beta) Fedora or a Debian testing.

Is it the good repo for Tumbleweed OpenQA test? [https://github.com/os- autoinst/os-autoinst-distri-opensuse](https://github.com/os-autoinst/os- autoinst-distri-opensuse)

<comment><AUTHOR> Yes, we share one test repo amongst all the openSUSE distributions and SUSE distributions

SUSE use openQA for testing their enterprise distributions too, and keeping all our tests together and reused as heavily as possible really helps in all directions (and proves the argument that maintaining openQA tests isnt hard even when dealing with multiple codebases-under-test all moving at different paces)

I use Tumbleweed as my daily driver on all my machines besides my server (Leap).

In 2 years I've had no problems that I didnt cause myself (eg. rm -rf /) and even then snapper saved the day and let me rollback to a working snapshot (Tumbleweed, like all openSUSE/SUSE distributions have btrfs snapshots and rollback by default)

So I'd say its comparible to Fedora or Debian testing

And we'd like to see more contributors, not only adding more packages and maintaining them, but to openQA also so that Tumbleweeds quality doesn't just stay at that level but gets even higher

<comment><USER4> Thank you a lot. I'll try Tumbleweed.

</comment></comment></comment></comment></comment><comment><USER5> This does all sound quite compelling. Somehow OpenSUSE has fallen under my radar, I've been an Arch user for a few years, and Gentoo user before that, and I'd only ever be interested in rolling distros, but I wasn't aware that OpenSUSE had Tumbleweed for this.

I did find dependency conflicts all too common on Gentoo, and keeping the system up to date was a frequent struggle. I've not had any major issues with Arch recently, and any that occur are usually fixed by doing a full system upgrade, but they do occur from time to time. I'd be interested to see how SUSE differs.

One thing I've noticed when doing a quick bit of reading on your Wiki - <USER2> sounds like you can't update Nvidia drivers from the package manager in Tumbleweed, and it has to be done manually. It also sounds like this process has to be done any time you update the kernel or X. This sounds like quite a pain - manually installing the nvidia drivers isn't exactly complex, but it's a number of manual steps that I'd rather not have to go through outside of the package manager every time I do a system update. Am I missing something here, or is this the case?

It also sounds like it supports installing with sysvinit rather than systemd, which is a rarity these days, and might appeal to some people.

<comment><AUTHOR> nvidia drivers - we don't recommend them because we have a habit of adding kernels quicker than NVIDIA can keep up with their proprietary drivers

If you really want to use them, I'd recommend the dkms drivers we have in OBS [https://en.opensuse.org/SDB:NVIDIA_the_hard_way#Further_read...](https://en.opensuse.org/SDB:NVIDIA_the_hard_way#Further_readings)

And yes, I believe if you want you can install with sysvinit, though we are primarily a systemd distribution first (with extensive sysvinit compatibility.. people still love those runlevels)

<comment><USER5> Ah, that's fine in theory then - I use a dkms package on Arch too since I use a non standard kernel with VFIO patches for PCI passthrough. Interestingly I see people have reported getting PCI passthrough working with the standard SUSE kernel too, so I'll have to give that a try.

As far as I can see the x11-video-nvidia package in the page you linked has quite an old nvidia driver version for Tumbleweed - [https://software.opensuse.org/package/x11-video- nvidia](https://software.opensuse.org/package/x11-video-nvidia)

Again I might be missing something, and in practice it might be easy to install the latest drivers, but this is a bit off putting. I don't know the details of how your build system works or why it keeping up with Nvidia drivers complicated, but this seems like it'd be quite a fundamental thing for a lot of users. The vast majority of people who play games on Linux are going to want recent proprietary Nvidia drivers, so having that as a footnote at the bottom of an article that says it's not recommended/supported doesn't inspire confidence.

Still, I'm intrigued enough to give it a try.

<comment><AUTHOR> The search seems to be doing something weird at the moment..

There is a second "openSUSE Tumbleweed" under the "unsupported distributions" category, and that has the more up to date nvidia packages I'd expect

If someone would like to take a look at the lovely ruby behind software.opensuse.org and fix that bug, I'm sure we'd love the pull requests :) [https://github.com/openSUSE/software- o-o](https://github.com/openSUSE/software-o-o)

</comment></comment></comment></comment><comment><USER6> The main problem these days is that people don't give a fuck about packaging their software for the constellations of distributions that exist. OpenSUSE topic-repositories usually offer the latest packaged version of most things for the Stable version too (say the Games repository), where available. But in many cases, latest versions are just not there for anyone.

We are in a model now where OS repositories have been replaced by npm, pip, rubygems in the best case. By pulling from Github's master branch in the worst (wink at Golang). In a sense, your system is already a rolling distro, except plugged to a third-party-managed repository which you trust to install packages produced by total strangers.

</comment><comment><USER7> That does sound pretty cool.

Who owns Suse again? Do they have a social contract? How's their democratic decision making? Do they properly separate non-free software from their free packages?

\- Debian User.

<comment><AUTHOR> and one question that doesn't get answered by that link - yes, we properly separate non-free software from our free packages

<comment><USER7> "Who Owns It" seems to be a company owned by a company floated on the stock markets. But with excellent community input.

That company is apparently actually making money selling at-least-mostly-free software, while supporting the properly-free openSuse.

Is that about right?

That's probably better than being Shuttleworth's toy.

Looks easily enough forked if needed.

I think I'd feel weird about going back to a OS supported by a for-profit rather than a charity, but that test suite does sound top.

I may give it a go for a while at least, next time I have to reinstall.

Cheers for making me pay some attention to it ;)

<comment><AUTHOR> I'd say that's a fair assessment :)

SUSE isn't your typical 'for-profit', and the nature of the relationship with openSUSE reflects that

Thanks for the consideration

</comment></comment></comment></comment><comment><USER8> I have some relatively fond memories of SuSE, because it was my first GNU/Linux distribution. Back then, it had the advantage of being pretty newbie-friendly (graphical installer / system control utility) and good ISDN support. Since ISDN apparently never became popular outside of Germany, not many distros had good support for it, and setting it up manually could be a real pain (at least for a newbie - a couple of years later, I set up a dial- on-demand ISDN router using NetBSD). So SuSE was, in retrospect a good choice for a first distro.

Eventually, though, I got fed up with YaST, because it used to overwrite config files and thus wipe out all manual changes one made to them. Does SuSE still do that? I remember reading about plans to rewrite YaST from scratch, so hopefully they found a better way of dealing with config files. From a UI perspective, YaST was a neat tool for non-techies.

<comment><AUTHOR> YaST was written into Ruby, yes.

These days YaST no longer overwrites config files, except from a very few corner cases where it really really wants to be in control of specific config files for very specific reasons. But if it notices local changes, it warns the admin and doesn't take over unless the admin consents

So, no more unexpected config file obliteration :)

(and even if it did, YaST is integrated with openSUSE's default btrfs snapshot tooling, so YaST takes a snapshot before and after it changes anything, so you could always revert)

<comment><USER8> Thanks for the info! I think I'll give it a try over the next extended weekend.

</comment></comment></comment><comment><USER9> So it automatically ships the latest versions of e.g. screen and vim, no manual recompiling/installing necessary?

That's always been my biggest gripe with other distros, they'd have a version of an app or tool that was built once years ago and never touched again. I'm _sold,_ I'll be taking Tumbleweed for a test drive tonight.

<comment><USER10> It is a rolling release, that means each time a new version of a package is available they will try and incorporate it. Apparently the difference they have to gentoo, arch et al is that they have a large CI that actually inspects screen shots to verify that the new package didn't break anything.

I run antergos (arch based) at home, having the bleeding edge is nice, but the AUR is really what seals the deal for me. That being said I have been cut by the bleeding edge at least twice, once so badly that it booted up without the eth0 interface. Maybe tumbleweed wouldn't have this problem as often.

<comment><USER11> CI tests as described are very good for minor patches, but new features and significant UI changes seem to require significant manual updates to tests anyway.

<comment><AUTHOR> You'd be surprised how little a problem it is in the real world

In the case of UI changes, openQA can have it's 'needles' updated in it's webUI. Look at the new screenshot, compare to the old screenshot, tell openQA to like the new stuff, done.

In the case of functionality or workflow changes, yeah, tests need to be adapted, but the openQA test writing language is pretty human friendly, describing the steps that humans actually do, so it's not that hard to alter

And because we test at the point of submission before anything is merged to the distribution, we generally catch the behaviour changes as part of the package submission, then we have developers keen to get their stuff in the distribution happy to help tune up the tests ;)

</comment></comment></comment></comment><comment><USER12> Ok, I'm a long time suse fan (ever since I dropped mandrake). But, mostly I run it in desktop VM's (openSuse) or on server class machines (sles). With the late 12.x series, it was working so well as a desktop OS in the VM that I decided to install it on a real piece of hardware and use it as a daily driver. That was a first for me in about 10 years. And it mostly worked on the laptop I installed it on. Wifi (including fn/enabled/disable buttons, and transitions between networks/wired/etc), suspend/resume, 3d acceleration/opengl, keyboard volume controls, etc all just worked. About the only thing that required futzing was the LCD brightness keyboard bindings were dorked (even though its a standard i3/etc machine) and the bluetooth was also broken. Three or four hours of recompiling modules, and messing with KDE/etc and everything on the machine worked. That made it the _ONLY_ laptop I've ever seen that worked without compromises in linux.

Fantastic experience, but with the 13.x series it seemed to go downhill a little. Enough that I stopped upgrading it because things break and I have to screw with it.

I wanted to like the leap concept, but it seems so many things were broken that the two days I spent trying to install it on a fairly normal x99 machine with a NVMe drive that I reverted it back to running it in a windows hosted VM.

I can't imagine what tumbleweed is like. Getting the kernel to boot and X to display graphics is just the first steps in my book. Plus, don't get me started on the UI changes. I want my desktop machine, and my servers to be _STABLE_. Screwing around with the bluetooth driver every time the kernel gets upgraded (or something similar) isn't something I want to be dealing with when I have actual work that needs finishing.

So, before someone tells me to try ubuntu/etc I'm going to say that I regularly run fedora/ubuntu/etc and they all have enough hangups that I continue to run opensuse based products at home (work has a different set of requirements, where I've been fedora/RHEL based recently rather than opensuse/sles).

Anyway, I really wish someone would take the leap type concept and stabilize the base OS/X/KDE and maintain it for a long time period while assuring that newer version of linux applications continue to work on that platform. You know, like windows (before 10). That way I won't have to worry that my 1 year old KDE version is to old to run a cd ripping application (or whatever).

<comment><USER13> This is just anecdotal as well, but I've been running Tumbleweed for at least a year now on my Thinkpad. It's been rock solid. I'm a Gnome user though which I think makes a huge difference in this case, I see a lot of noise about problems with KDE.

</comment></comment><comment><USER14> Seems like a step forward in solving the "stale versus reliable" conundrum. Over the years I've repeatedly been irked by how stale the package repositories are in some distros. At the fresh end of the spectrum, I used Gentoo for a while, and I do like many things about Gentoo, but I came to the conclusion that it is essentially impossible to QA Gentoo. Plus, falling behind in Gentoo opens you to a world of hurt trying to update.

So I'll probably try Tumbleweed. I think the acid test will be how hard it is to update a few-months old installation. Testing each release is one thing -- testing all variations of update paths, again, leads to combinatorial explosion. Perhaps they have an update mechanism that deals with migration issues -- I'd like to understand how they approach that problem.

<comment><AUTHOR> zypper takes care of most of that for us - it really is an exceptional package manager

We have some tests in openQA that keep an eye on upgrades, as well as some users who like to stagger their Tumbleweed updates for some weeks.

I think the record I heard was like 3 months (and our gcc5 migration happened during those months), and then they upgraded with no problem

<comment> semi-extrinsic 3 months? That's peanuts. Having too many Arch boxes, back in '12/'13 I had one that was 9 months behind, with the big filesystem movearound and sysvinit->systemd change happening in that period. It took a couple of hours of work, but the upgrade went through fine in the end.

I'd suggest you do automated testing of at least 6 month old system upgrades. Because users are going to do it, and much complaining will ensue when it breaks their system.

<comment><AUTHOR> We do automated testing from our 'traditional' distributions, including versions that existed BEFORE Tumbleweed in it's current form..like 13.1, 12.3, etc..

So in that case, we're going back years ;)

</comment></comment></comment></comment><comment><USER15> Is this guy leaving out periods as some kind of intentional stylistic thing, or did he just fail at proofreading? Lots of other typos too. A little ironic when you're writing about doing things correctly and testing comprehensively!

<comment><USER16> You've unfortunately been massively downvoted for saying this, but I think you're right. Also, in _Tested Well_ just before the screenshot I couldn't understand the sentence "And if we don't test it well enough we want to and you can contribute tests as everything in [openQA is 100% open source]."

The author mentions at the bottom that it was inspired by a Reddit article, so I think this was just thrown together in rapid-fire response style with little proofreading.

I think it's the nice color scheme and well-picked fonts that clash - we've all come to expect perfect typography when presented with good site design, and it's a bit of a shock.

Definitely hope the article gets cleaned up, because the content is really compelling.

<comment><AUTHOR> Will do..thanks for the critique

<comment><USER16> It probably didn't come across as well as I was hoping, but I wasn't going for a scathing-review motif. I could probably have couched my response a little more comfortably though. Kudos for the brave face and the positive reaction :)

Also, I didn't make the connection that you were the article author (!) - <USER3> followup on here has been admirable and impressive. Not many of the people who submit OC (of sorts) also follow up.

And thanks for writing this, it's definitely made me very curious about trying out OpenSuSE - or more accurately why I _would_ try it. I'm using Arch at the moment, but I might be exploring in future :)

The AUR is pretty amazing, though... I don't use it that much, but it's nice that I've been able to install the stuff I have wanted with a single command. I get the impression there isn't a comparable alternative to this for SuSE...?

<comment><AUTHOR> There is the graphical option, using [http://software.opensuse.org](http://software.opensuse.org) and the 1-click install functionality there to add packages direct from OBS

on the commandline, there is a plugin for osc (the OBS commandline tool) [https://build.opensuse.org/package/show/openSUSE:Tools/osc-p...](https://build.opensuse.org/package/show/openSUSE:Tools/osc- plugin-install)

This enables 'osc install $foo' which will search the build service for package $foo and install it, which I believe to be the closest approximation of what you expect from AUR

<comment><USER16> I noticed the 1-click install system, that's kinda cute :P (I have a vaguely similar experience when I go, er, Slackware package fishing.)

It seems to me that OpenSuSE (and SuSE itself) follows a philosophy of using centralized build management and verification, with a policy that supports minimal (if any) local from-source recompilation. Basically the exact opposite approach to Gentoo, the only distribution where gcc is more important than eth0 :P

This centralized model is actually exactly what I've been pining for for a very long time - an approach that a) verifies that XYZ works right in a central location, then distributes that known-working configuration, and b) creates an environment where clients are built using solely using such known- working configuration objects, and are thus relatively easily reproducible at scale.

I'm obviously testing OpenSuSE sometime in the short to medium term :D here's hoping it works out well for me in practice!

I'd heard of the OBS, but I didn't know the (Open)SuSE ecosystem was wrapped around it quite like I do now.

The one question I do have now is, where do you think OpenSuSE sits in relation to functional (ie static/absolute) package management? The distributed-known-working-blob approach sounds like it would fit in incredibly well with a model like what the Nix package manager uses.

Of course the current OpenSuSE ecosystem doesn't use this approach so adding it tomorrow would provide nothing unless everyone shifted mindsets, which would naturally not happen anytime soon. I'm just curious about what would happen if the two ideas were combined, since they don't seem to be particularly mutually exclusive or conflicting, and the result sounds like it might be potentially shiny and interesting (and possibly very powerful). And non-relative configuration sounds like the future (to me at least).

</comment></comment></comment></comment></comment></comment><comment><USER17> Things that prevented me from using OpenSuSE:

1\. no single letter user name allowed in the installer

2\. yast rewriting config files

3\. I couldn't get the partitioning tool to do what I tried which is plain simple /boot plus encrypted swap and root.

<comment><AUTHOR> 1\. kinda true, though the current version of the installer lets you skip the username creation so you can do whatever you want afterwards :)

2\. formerly true - YaST lives happily with config files these days. When possible it co-exists, only a few specific YaST modules need that absolute control and only rewrites them by warning you well in advance. ie. Not true any more

3\. I think we fixed that..it's a radio button now.. Encrypted LVM-based proposal [https://lizards.opensuse.org/2016/03/15/highlights-of- develo...](https://lizards.opensuse.org/2016/03/15/highlights-of-development- sprint-16/)

<comment><USER18> where can I find exact documentation about which config files are still manipulated / changed by yast and which are not?

<comment><AUTHOR> the only one I can think of is the apache one. If you use the YaST apache configuration module it will warn you before taking over and changing any local changes. It actually does its best to do a merge of local changes and its own, but it's the one case I know of where that merge can be destructive.

<comment><USER18> Thank you very much for your attention - however I asked where I can find exact documentation about these things?

"Mr Brown from Suse wrote in a HN thread..." will not be enough as a reliable source of information. Yes, I could just read the source, however I am expecting such an extraordinary important thing that will change my config files to be documented. I need precise information here.

Also it would be important to know how this conflicts with configuration management systems like chef, ansible, puppet etc. - or is yast able to manage multiple workstations itself, so is is a replacement for these tools?

Thanks!

<comment><AUTHOR> There is pretty extensive documentation on [http://yast.github.io/documentation.html](http://yast.github.io/documentation.html)

It doesn't conflict with other configuration management systems. I've used openSUSE extensively with puppet and saltstack.

Many of SUSE's products use other configuration management systems as part of their toolchain, and SUSE are shipping SUSE Manager 3.0 with SaltStack, so their customers are expected to be able to use YaST alongside such a system

<comment><USER18> Multiple 404 on that page:

[http://www.rubydoc.info/github/yast/yast- yast2/](http://www.rubydoc.info/github/yast/yast-yast2/)

[http://yast-core.readthedocs.org/en/latest/](http://yast- core.readthedocs.org/en/latest/)

I am not trying to make you angry, but I think I put the finger right on the place where it hurts very much.

There is no clear documentation about what yast does or what it will not do - basically a blackbox. Maybe it will change apache config. Maybe not. Who knows.

<comment><AUTHOR> :) fair point..I'll let the YaST team know (or you could if you happen to be on freenode, they live in the #yast channel)

Users know - YaST doesn't change stuff without telling you, that was the point I was trying to make earlier. Users of YaST no longer have to worry about it silently taking over config files, it either co-exists or doesn't do anything without telling the user with great big pop-up boxes first

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> OpenQA seems really brilliant, but I guess someone could eventually just port it to Arch, Gentoo, Debian, or Fedora Rawhide? I hope they do.

<comment><AUTHOR> Sure they can (and Fedora are already using and contributing to openQA)

But you really need to be using OBS too in order to produce those builds in the fast, easily contributed way that we then (ab)use with Tumbleweed

Of course, other projects could use OBS also..either hosting their own or by using our servers even..after all it builds Arch, Debian, Ubuntu, Fedora and other packages

But that's what being open is all about right? Doing cool things because you need them and then benefiting even more when everyone else finally catches up and starts working with you on it :)

</comment></comment><comment><USER20> So for every library Foo, it tracks all of the packages that depend on Foo? What if I add my own package -- do I have to tell Foo about mine as well? What if Foo's API changed or breaks my package?

<comment><AUTHOR> Yes, the open build service takes care of that for you

You don't need to tell Foo about your package, the build service will detect those relationships

If you build against Foo, and Foo changes, the OBS will rebuild your package for you

If it breaks your package, the OBS will keep the last version published while you can debug the build failure

</comment></comment><comment><USER21> Well, this might just replace my current Debian setup as a daily driver. I've been wanting something like this for a while but had no idea how to do it technically in a feasible way. I guess you've done it for me.

Thanks for posting this and (if you still read this) the thorough followup in this thread.

<comment><AUTHOR> My pleasure :) thanks for reading!

</comment></comment><comment><USER22> I've stuck with openSuSE/SuSE since the early days, and doing Tumbleweed since about when it surfaced. There are several reasons I didn't switch over to Ubuntu (and a few reasons I wanted to, but the pros outweigh the downsides for me).

1\. Active Directory: I'm not a Unix shop and everywhere I've had a need for it, AD has been the predominant identity service in the environment. Getting openSuSE setup, via yast, to work with my AD account is _really simple_. It can be done everywhere else, too, but being able to set it up during installation without touching a config file is nice.

2\. Bleeding edge: I like to play and Tumbleweed was always on a later kernel (and other core bits) than other distributions, giving me access to the new toys early on with the "feeling" that I'm not running "beta" (and feelings aside, I've not run into anything on the stability, yet). Never having to think about doing a "distribution upgrade" (because you're basically doing it in pieces every time you update) is nice, too.

3\. YaST: Much like the easy AD integration, there's a whole mess of administrative things that can be done without editing configuration files or using console tools that I'm not in nearly enough to memorize their usage. Simple things like opening a port in the firewall are as easy as they are on a consumer router and the ncurses interface is perfect over an SSH connection (I haven't used GUI YaST but it looks nice, too). People always say Ubuntu is the most "n00b" friendly Linux distribution, and it probably is when the large community behind it is factored in, but I find SuSE to be superior, personally.

On the downside, though:

There's less available in Zypper. I get jealous when every answer in StackExchange includes an apt-get and about 15% of the time no package even exists for whatever it is that I'm being told to apt-get. But it's little more pleasant to watch on the console.

The smaller community makes StackExchange less useful and they use different tools. Much of it is due to the bleeding edge nature of Tumbleweed and I've read plenty of "it's better, that old stuff will be deprecated everywhere else, too" and I can't speak to the merits of any of that, but when my network connection goes south, I instinctively reach for "ifconfig" and it's not there. And all of the help out there points me at things that don't work, either[1]. And because it's a rolling distribution, these kinds of changes don't pop up when you expect them (like when you're doing a distribution upgrade...)

Tumbleweed's rolling update model has thoroughly broken on me, once, but not in a "hey, it just decided not to boot this time" kind of way. I believe this happened when they switched to "Leap" and "Tumbleweed" as the only options. I thought I was up-to-date, but I was pointing to repos that were invalid and had to modify my configs and download an .rpm to fix it. Other than not seeing software updates (which is pretty odd since there's usually something _every time I update_ ), there was no indication that anything was wrong.

Out of the box, sudo isn't setup (maybe it is, now, I haven't done a fresh install in a long time). It's not hard to get working, though.

[1] It's one of the new "ip _something_ " commands I can never remember when I need it: [http://www.linuxfoundation.org/collaborate/workgroups/networ...](http://www.linuxfoundation.org/collaborate/workgroups/networking/net- tools)

</comment><comment><USER23> With the recent announcement of Neon by KDE, and the rising popularity of Arch, and Fedora trying to get more modular (with multiple release versions) I can't help but feel the market is way oversaturated, but everyone is bringing something to the table better than everyone else. If we had a unified distro set rather than bascially four reimplementations of the same thing, we could be seeing a lot more momentum towards desktop Linux's adoption.

In general, there are two users of desktop distros:

A. Professionals and grandparents, who want stable, unchanging systems with long support. Think your SUSE Leap, your RHEL, your Ubuntu LTS, your Debian Stable, and kind-of-not-really Manjaro.[1]

B. Enthusiasts, developers, power-users, and gamers(!) who want the latest and greatest software. These are the SUSE Tumbleweed, Debian Testing, Ubuntu- nonLTS users (with a ton of PPAs), Fedora Rawhide, and Arch users. They don't want unstable software, they just want to get new stuff when the makers actually release it rather than have computers frozen in time - which in practice, no other OS actually does.

Nobody else is trying to ship an OS that intentionally holds back upstream released new releases, unless you consider the tiered versions of OSX / Windows / Android like that, except their availability is more based on your willingness to spend money / upgrade your device to get them than them just being delayed.

[1] I think there might be a schism between these two even further - grandparents probably want Neon style desktops just because individual distros are not honoring the release cadences of major projects like KDE or Gnome. Plasma 5.6 just came out and will not be in Ubuntu 16.04 alongside Qt 5.6, despite both fixing a tremendous number of bugs and issues with the desktop. That isn't cutting edge features, that is bug fixes, and I don't really believe in holding back major project releases like KDE or Gnome regardless of distro. Just have a switch to pin it if its corporate. But there is a tremendous lack of communication between upstream when major software projects like KDE cannot bugfix their major userbases at all for years (IE, Ubuntu LTS).

A great comparison would be to the Android world. Google devices see continuous releases for their support periods monthly now, like fixed release distros. Cyanogenmod has daily releases like a rolling distro. Any non-Google phone basically never gets updates and plays Debian Stable. But _all_ of them, when using the Play Store, will upgrade every user facing APK on the system whenever updates are available, because those updates are not Google's responsibility, they are the developers, and users are used to knowing it is the app makers fault when something breaks, not the distributor (Google Play). General adoption of the Linux desktop requires this distinction be made, where developers can both easily offer their software to Linux users and be held responsible when they break it, rather than having everything filtered through distros that will basically throw the baby out with the bathwater by freezing all software because they trust nothing.

But on topic, it seems like we now have a half dozen different solutions to the same problem. Why can't I have a distro with SUSE's infrastructure, Ubuntu's brand and userbase, Debian's community, and Arch's software availability? It is like everyone has their own piece of the pie perfected but rather than us having a whole pie to solve any of these 2/3 use cases (I'd consider the server use case is _extremely_ well provided for nowadays, the only domain Linux distros are doing a good job at, between RHEL / Stable / Ubuntu Server). It isn't even really about different distros for different desktops anymore, since pretty much every desktop is available on every distro - either officially like in Arch / Debian, or through the software universe of Ubuntu / SUSE / Fedora. The distinguishing factors are just the holes the other distros will not fill because they are too busy fixing another problem unaddressed at home.

It does not help that the work is then duplicated across all these projects. Packaging Qt and KDE are a pain in the ass, but there are four release teams between all these distros maintaining those releases independently. There is no actual way to fix this - the Debian, SUSE, Ubuntu, Fedora, and Arch devs have already dug in within their camps - but it is still sad that desktop Linux remains niche because rather than working together and combining the best of everything we have everyone is working on their own thing while the whole is lackluster against the competition.

</comment><comment><USER24> Yes, you should use weed.</comment>


Ask HN: Compensation/cost of living NYC? - <AUTHOR> A friend got a job offer in NYC (moving there from out of the country).
In NYC, as of now, what is your take on:
- typical junior-mid engineer salary
- typical take home salary monthly on that (net)
- typical rent for a studio in a reasonable neighborhood
(I understand it will vary wildly, but good to get a sense)
Thanks! <comment><USER2> My first job in NYC as a junior engineer a decade ago was 110k plus equity.

I rented a single long hallway-like room basement studio in Chelsea for 2k/month. Good neighborhood if you are a gay man or like art galleries. Recently got the elevated railway turned park going through it as an added benefit.

My girlfriend had a nicer basement studio in the East Village for $2.5k/month. Nice for the younger NYU crowd that likes to go out to bars and clubs like Webster Hall.

Basements are the worst. Your view is bad, your lighting is bad, you smell the garbage all night on garbage days, piled up on the street, and you have bug attacks like ants and termites all summer - that's why they are cheap.

A friend with a studio above ground near City Hall Park in a doorman building with a pool in the basement is paying $5k/month. I know someone paying $8k for a really nice 1 bedroom on a high floor with glass walls in the theatre district.

We were all on the subway in Manhattan, though. The really poor people have to bus over from NJ, or live an hour subway ride away like north of central park like Washington Heights. Those people are just suffering with a long, poor commute to save money, though.

</comment><comment><USER3> Short answer:

\- rent is a bit higher than other high-profile cities, but significantly less (by a third, some say) than SF

\- other costs vary widely, but depend on how "sweet" you want your lifestyle to be (just like anywhere else).

But surprisingly, in terms of food, drink, and cultural offerings, on a day- to-day basis you can actually live in NYC quite cheaply (if you know where to go and what to look for).

</comment><comment><USER4> your going to need at least 100k to live in the city in a decent studio.</comment>


Kindle Fire owners: Post screenshots/video of programming PDF on the Kindle Fire - <AUTHOR>

I'm considering purchasing a Kindle Fire in order to consume the numerous programming PDF books that are all the rage these days.  For cost reasons, I'm hoping the KF can do a decent enough job over the iPad so I can save the extra cash.<p>Would appreciate photos/screenshots/videos of a Kindle Fire with a programming PDF on it's display. <comment><USER2> May want to ask some users who have received their units to post up for you here: <http://www.kindle-fireforum.com/></comment>


Firefox to support Google's WebP image format for a faster web - <AUTHOR> https://www.cnet.com/news/firefox-to-support-googles-webp-image-format-for-a-faster-web/ <comment><USER3> WebP lossy and WebP lossless often get mixed up. They are substantially different. While the former is mostly just outdated VP8 4:2:0, it is fast and more pleasing to the eye than JPEG at _low_ quality and more practical there, given it has transparency. The latter is a pretty good option for ARGB images offering 25% improvement over PNG [1], and 20-40% on top of that with near- lossless compression.

[1] [https://developers.google.com/speed/webp/docs/webp_lossless_...](https://developers.google.com/speed/webp/docs/webp_lossless_bitstream_specification)

<comment><USER4> Not only that, but it's also MUCH faster than PNG in both decoding and encoding. I use it for all images I store as lossless.

</comment></comment><comment> dao- People point out that WebP isn't ideal, that there are better alternatives etc.

All that may be true, but the most relevant factor here is Google and Microsoft backing WebP. Google has the power to push through its own inventions due to Chrome's market share. If you want less of that, use Firefox.

Meanwhile, Mozilla hasn't given up on better formats, as the article points out.

<comment><USER5> While I like a lot of the new capabilities of the web, I sometimes feel like it's Google strong-arming them into existence, and the rest has to follow.

<comment><USER6> Which makes Google Chrome a modern day IE. They push basically proprietary nonsense into the web that eventually gets scrapped or forced into being an open spec at which point its harder to redefine since it became a "works on my browser" implementation.

<comment><USER7> Except that the problem with IE was stagnation in era of IE6, not new standards backed by patent free and open source libraries.

<comment><USER8> The _original_ problem with IE was its implementation of early CSS drafts - <USER2> open standard with specs. They just picked the "wrong" version of such specs and pushed it with their commercial strength. Everyone else was then caught between the choice of implementing the real (better) spec, or lose compatibility with IE.

Similarly, Google now picks the standards it likes, and everyone else is caught between the choice of investing in those or lose compatibility with Chrome. Not much of a difference.

<comment><USER7> I feel that Safari (mobile one) is way closer to the IE6 status with its ban of competition on platform, lack of standardised features and heavy handed management.

You can easily replace Chrome, it's not even a platform default. You're forbidden from replacing Safari.

<comment><USER9> I had thought that Chrome's Blink engine was the platform default on Android. But I am not sure.

How does a web developer test for Android compatibility? I have been testing against Chrome only.

<comment><USER10> Chrome on iOS is just wrapper around safari WebKit.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> That's surprising. I was under the impression that it was already supported since they support WebM.

The Wikipedia article [0] says they started evaluating adding support in 2016. Following the source links to this bug report [1]. From a quick glance at the discussion there, it's not obvious to me that they've settled on adding in WebP support.

What we need is buy-in from Apple. Although I'd be much more excited about them adding WebM support so we can finally drive the last nail in the GIF coffin. Does anyone know why they pulled it out? If I had to take a shot in the dark, maybe it doesn't perform well on mobile or it consumes too much power?

Maybe this is a dumb question, but why will we be supporting both WebM and animated WebP? According to the Wikipedia article, WebP also has animation support.... But isn't that kinda redundant? Do they solve different problems? You can just create WebM containers without an audio stream.

While we're on the subject of adding new image formats to the web, does anyone know if there's any interest in adding FLIF support [2]? When it came out it seemed much more interesting to me, but it looks like it never picked up steam.

As an aside, can I just say fuck CNET? Here they used a shitty linking practice which I always find incredibly annoying. Instead of linking to primary sources, they add some useless tag links along with references to old CNET articles. How about linking to the relevant bug reports, asshole?

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

[1] [https://bugzilla.mozilla.org/show_bug.cgi?id=1294490](https://bugzilla.mozilla.org/show_bug.cgi?id=1294490)

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

<comment><USER12> > why will we be supporting both WebM and animated WebP?

From: [https://developers.google.com/speed/webp/faq](https://developers.google.com/speed/webp/faq) (Why not simply support WebM in <img>?)

WebM uses more memory, it is less widely supported, uses more resources when playing, and is currently less efficient compression-wise than WebP.

About FLIF, I was recently checking it and it's indeed a very interesting format. Notably because it can be used on any type of image. I assume it hasn't pickep up steam because it doesn't have the backing of any big sponsor. Google is pushing WebP, and introducing another format at this time is probably not worth it.

<comment><USER13> FLIF is interesting, yes, but after doing some more research into it I came to the conclusion it doesn't hold any promise as an image format for the web.

The progressive streaming is a cool trick, but if you actually use the progressive stream to embed lossy images in your web page, you end up with lower quality than if you had just used JPEG in the first place, never mind something newer. The difference was pretty stark.

</comment></comment></comment><comment><USER14> WebP is reasonably fast, this can't be said about the other image formats. I tested WebP, FLIF and BPG when I was looking for a PNG alternative and WebP seemed to be the best choice all-around. The only downside of WebP is that it doesn't work with images larger than 16383 pixels in width or height.

<comment><USER15> 2^14 pixels in both directions with 4 bytes per pixel (ARGB) puts the pixel data at a maximum size of 2^30 bytes. Just barely enough to be indexed using a 32-bit integer (even a signed one if you want)

<comment><USER16> Looks like WebP uses RIFF data chunks [1] (which look a lot like the old Amiga IFF file format), and the size of such a chunk is a 32-bit integer. Besides, 16k width/height ought to be enough for anyone ;)

[1] [https://developers.google.com/speed/webp/docs/riff_container](https://developers.google.com/speed/webp/docs/riff_container)

<comment><USER17> I take photos of trains [1] and regularly run into file format limitations as the photos can easily reach hundreds of thousands of pixels wide.

Besides, modern cameras such as the Sony a7R II are already producing photos 8000 px wide, and the upcoming 100 megapixel cameras such as the Fujifilm will do 12000 px wide images. It's very easy to hit the limit if you're planning to shoot any panoramas.

[1] [https://commons.wikimedia.org/wiki/User:Dllu](https://commons.wikimedia.org/wiki/User:Dllu)

<comment><USER18> If the raw size is approaching 4GB maybe it's fair to split the image..

Anyways, webp is for websites not cameras..

</comment></comment></comment></comment></comment><comment><USER19> That's too bad. WebP was a bad idea released several years too early, now it's stuck with VP8 and the only color format is 8-bit 4:2:0 which is just not good enough. Please don't use it.

<comment><USER20> It's better than JPEG and PNG for most uses, with smaller image sizes. Even 4:2:0 is better than the sRGB usually used in PNG. I'd rather have this now than wait another few years for a few niche usecases (where TIFF can still be used)

<comment><USER19> You can use AV1 or HEIF right now, and they're actually modern formats.

> Even 4:2:0 is better than the sRGB usually used in PNG.

Better for what? Not for wide-color photographs or any kind of colored text, that's for sure.

<comment><USER21> Afaik there is no av1 or heif browser implementations. Theres far less efficient polyfills for heif that are poor on large images.

<comment><USER22> Chrome 70 Canary and Firefox Nightly support AV1. YouTube has a test channel with AV1 encoded videos.

[https://9to5google.com/2018/09/14/youtube-av1-video-beta- chr...](https://9to5google.com/2018/09/14/youtube-av1-video-beta-chrome/)

<comment><USER21> That is very, very new, and afaik it uses the poorly performing reference Implimentation.

</comment></comment></comment></comment></comment></comment><comment><USER23> Strange to cave so late in the game with AVIF right around the corner. This article really doesn't explain why.

<comment><USER24> Unless I'm mistaken, while AVIF may be "right around the corner", it's still quite a way off relative to the speed of technological advances. Unless I'm mistaken AV1 is very far from finalized or being a realistic option for the web, and as AVIF will effectively just be a still-image subset of AV1 it's going to take some time as well. (I'm still very excited about it, however.)

I suspect they might be motivated by the rapid way in which HEIF seems to be taking over. My understanding is that comparatively, the patent situation of WebP is much better. If you're a company concerned about software patents on the web, it might suddenly seem that throwing your weight behind WebP as a way of avoiding the proliferation of HEIF is worthwhile.

<comment><USER25> > _Unless I 'm mistaken AV1 is very far from finalized_

AV1 is finalized: [https://aomedia.org/av1-features/get- started/](https://aomedia.org/av1-features/get-started/)

I think there are a couple bugs and contradictions between the spec and reference implementation that are being ironed out, but the bitstream is now frozen.

<comment><USER26> The copy of Firefox that I'm using to type this has the AV1 library linked to it (via ffmpeg).

</comment></comment></comment></comment><comment><USER27> Great, but we really need Safari to support WebP since that is the only option for iOS mobile devices.

<comment><USER28> Doesn't Safari support JPEG 2000 in exchange? And Safari was the one that introduced the newer picture element for enumerating responsive image choices (though to the dismay of HTML semanticists as HTML rather than CSS) wasn't it?

<comment><USER29> Not really, Firefox and Chrome supported the picture element well before Safari did. It was part of the nascent HTML5 standard.

I believe what WebKit introduced was the analogous CSS image-set property, which likely influenced the picture's element's development (but image-set still hasn't managed to escape draft-spec territory).

</comment></comment></comment><comment><USER30> To my eyes, Fabrice Bellard's HEVC-based 'BPG' looks even better at the same sizes, so I'd love to see it more widely supported, too. See:

[https://bellard.org/bpg/](https://bellard.org/bpg/)

<comment><USER31> ... except you need to pay loads of money for the (edit: HEVC) license

<comment><USER32> Why? The "licensing" information at the bottom of the page makes it seem like it's open source?

<comment><USER33> Open Source does mean it is free of patents.

<comment> yjftsjthsd-h Does _not_ mean it is free of patents.

<comment><USER33> Oops, right. I really thought I wrote this. Sorry.

<comment> yjftsjthsd-h Yeah, I assumed it was just a typo, but I figured we wanted to be absolutely clear here.

<comment><USER33> I promise I will never become a lawyer or write math books.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER34> Good to see Firefox join the party, even tough it's 4 years late. Serving multiple content types based on the http accept header sent by the browser is easy to setup. [1] So Chrome and Firefox users can benefit from the better webp compression while Safari and IE can stick to jpeg. [1] [https://wooptoo.com/blog/serving-webp- today/](https://wooptoo.com/blog/serving-webp-today/)

</comment><comment><USER35> Have browsers started deprecating any image formats to decrease bloat?

<comment><USER36> I'd like to see the opposite; Browsers having support for more image formats, especially the legacy ones from 20+ years ago (PCX, ART, ILBM, MAC etc.). That way interesting and useful imagery from days gone by aren't lost forever when the few remaining decoders never get ported to newer operating systems.

</comment></comment><comment><USER37> People compare it to JPG or PNG. I think the main point is for deprecating GIFs, with their poor quality and very slow processing.

</comment><comment><USER38> Congratulations! It took them only 8 years to implement WebP. Here is the original bug: [https://bugzilla.mozilla.org/show_bug.cgi?id=600919](https://bugzilla.mozilla.org/show_bug.cgi?id=600919)

</comment><comment><USER39> Are there any technical details on that? For example would Firefox send Accept headers with image/webp?

<comment><USER29> It would essentially have to, in order to support WebP as the web uses it.

</comment></comment><comment><USER40> This is fantastic to see. I hope Firefox will also isolate sites for better Spectre protection like Google did with Chrome. Takes more RAM but the added protection, IMO, is well worth it.

Had heard they are working on it. But had not heard a date?

</comment><comment><USER41> Mobile web consumption is now the majority of web engagement. Given that, iOS Safari's reluctance speaks volumes. I bet this has anything to do with technology, and more with Apple's business rivalry with the open web.

Given how iOS Safari is the least standards compliant browser of our time (other than the now defunct IE), I'm surprised they even implemented webassembly & webRtc (they didn't implement the data channel)

<comment><USER42> _webRtc (they didn 't implement the data channel)_

That is not correct. I've used WebRTC data channels myself on iOS and it works fine.

<comment><USER41> Can you link to a WebRTC Data Channel URL that works on iOS Safari?

Here's a simple WebRTC DataChannel demo that doesn't work on iOS 12.0 Safari

[https://webrtc.github.io/samples/src/content/datachannel/bas...](https://webrtc.github.io/samples/src/content/datachannel/basic/)

<comment><USER42> I'm afraid not – none of the available demos seem to work, but I don't know why that would be the case. All I can say is that I worked with the technology pretty extensively, and was absolutely able to use a data channel between Chrome and Safari 11 on both desktop and mobile without any issues.

<comment><USER41> It doesn't work because iOS Safari hasn't implemented WebRTC Data Channels.

<comment><USER42> I'm sorry, this is not correct. Like I said, I used data channels in Safari on iOS only a few weeks ago, and I'm not making that up!

Since you're not convinced, I looked into it a bit more, and the reason most of the available demos don't work is down to a difference in behaviour between Safari and other browsers, probably to do with address selection for the connection. WebRTC can leak private network configuration in some cases, so Safari seems to be pretty strict in that it requires `getUserMedia` to be called before allowing a data-channel-only to be established.

I made this into a small demo ([https://codepen.io/anon/pen/GYrqGL](https://codepen.io/anon/pen/GYrqGL)) and you can see after a couple of clicks of 'connect' that a data channel connection is established and works as expected. This is a bit of a privacy/usability tradeoff. But data channels are very much implemented in Safari.

<comment><USER41> Thanks for the clarification. Your time is much appreciated!

Cheers</comment></comment></comment></comment></comment></comment></comment>


The Great American Humbug (1865) - <AUTHOR> http://www.laphamsquarterly.org/swindle-fraud/great-american-humbug <comment><USER2> _" Hypocrisy is the homage that vice pays to virtue"_

Well, there's my quote for the day.</comment>


Show HN: Does it use Cloudflare? - <AUTHOR> http://www.doesitusecloudflare.com/ <comment><USER2> This doesn't detect Cloudflare CNAME clients.

For ex. It says uber.com is not vulnerable - because the homepage isn't, while the app is consitantly one of the most impacted in the caches I've seen

I don't think anyone has really nailed the methodology here - and I think that is important (as is erring towards false positives rather than false negatives) for security mitigation advice

<comment><USER3> It's not that easy. Not all CNAME clients used the three services that had the issue.

These lists are bad, because they list any Cloudflare clients that can be found, not just the ones that might have had exposed data.

</comment></comment><comment><USER4> Why was this flagged? Can HN offer a mouse over description to answer these types of questions? just curious

<comment><USER5> Individual users have the ability to flag posts (after a certain karma, I think) and there's no place to provide a reason.

<comment><USER6> To elaborate, flags are (nearly?) always the result of user action, not mods.

</comment></comment></comment><comment><USER7> Does this use live data? Would a site be positive even if it, after the publication of Cloudbleed, migrated away from Cloudfare?

<comment><USER8> "Live" is somewhat misleading here: the leaks are out there, in crawler caches. Do you consider such source "live", even though it is no longer leaking data?

<comment><USER9> I think that's exactly what the commenter was getting at. "Live" data would be deficient in this instance, historical data would be better.

</comment></comment></comment><comment><USER10> otherwise :

dig website.com +short | head -n1 | xargs -- whois | grep -q cloudflare

<comment><USER11> doesn't work with my setup, whois on cloudflare domains do not inlcude the string "cloudflare". This works tho:

      dig website.com +short |  grep -q cloudflare

</comment></comment><comment><USER12> Dang, this one's probably going to be more popular than mine.

[http://cloudbleed.surge.sh](http://cloudbleed.surge.sh)

Of course, mine isn't exactly performant, was the result of about 15 minutes of work, and just uses that Github repo with the list of affected domains (so, not exactly the most comprehensive). But hey, it was fun to build.

</comment><comment><USER13> My jekyll based static site hosted on Github Pages uses cloudflare for https. Saying that my site is compromised by CloudBleed is a bit too much.

[http://www.doesitusecloudflare.com/?url=www.stacktoheap.com](http://www.doesitusecloudflare.com/?url=www.stacktoheap.com)

<comment><USER14> But it is compromised.... this is literally the only use case in which you can get comprimised. If you put your _http_ page behind cloudlfare https

<comment><USER15> if it's public static content what exactly has been compromised?

<comment><USER16> IP addresses of visitors? Depending on the site or visitor, that could be theoretically a compromise.

But the parent comment is untrue. Cloudflare will have unencrypted data in memory at some point, even if it's encrypted coming and going. This is how they eliminate the scary browser message about self-signed certificates, ironically.

<comment><USER17> They have a (more expensive) version that encrypts all the way to your own edge.

</comment></comment></comment></comment></comment><comment><USER11> This is at about 38 upvotes ATM, and I believe it may not be killed for anybody's whims after that. It's tech-related, actual, and liked by the community here (not that is of particular interest to me but still).

</comment><comment><USER18> I was literally just saying to someone that this sort of tool needed to be made. Good job!

</comment><comment><USER19> Doesn't detect Reddit, which I understand to be affected?

<comment><USER20> According to one of the reddit engineers, they stopped using Cloudflare prior to when this issue started.

[https://www.reddit.com/r/programming/comments/5vtv16/cloudfl...](https://www.reddit.com/r/programming/comments/5vtv16/cloudflare_have_been_leaking_customer_https/de5awy9/)

</comment></comment><comment><USER21> Time to move to Incapsula

</comment><comment><USER22> news.ycombinator.com ... OMG!</comment>


Microsoft Believes It Is Going to Die (2014) - <AUTHOR> http://www.pcmag.com/article2/0,2817,2468651,00.asp

<comment><USER2> WUT?

"Android should be seen as just an iOS clone, which it is."

Android is dramatically different from iOS, not just from the user's perspective but from the developer's as well.</comment>


DRDoS, UDP-Based protocols and BitTorrent - <AUTHOR> http://engineering.bittorrent.com/2015/08/27/drdos-udp-based-protocols-and-bittorrent/

<comment><USER2> This is going to be exploitable for a long time.

BitTorrent clients often use UPnP to forward ports automatically. Many Windows users remain on old uTorrent versions after multiple unwanted "features" (advertising, built-in bitcoin miner, ...).

On the bright side, open source BitTorrent clients appear to have low amplification factors (libtorrent does 4x vs 40x for uTorrent).

<comment><USER3> Does this also affect UPnP? The article mentions only µTP

<comment><USER4> In this context, UPnP is what allows uTP to be used as a reflector, since the target reflector will have their ports opened automatically by UPnP (normally a NAT would block it).

That said, improperly configured UPnP can also be used to perform DRDoS via SSDP.

</comment></comment></comment><comment><USER5> Off-topic:

I really thought this was about DR-DOS, Novell's version of DOS.

[https://en.wikipedia.org/wiki/DR-DOS](https://en.wikipedia.org/wiki/DR-DOS)

<comment><USER6> Thanks! I was going to write the same comment, and I don't think it is off- topic.

Many HN readers probably won't understand the word-play behind "DRDoS", as they are too young to have worked with MS-DOS/DR-DOS/etc. So I think it is worth mentioning that this title is a word-play.

</comment></comment><comment><USER7> I wonder if there's a connection between this discovery and the articles [1] about the pirate bay's tracker targeting random ip addresses happening a few months ago.

[1] [https://torrentfreak.com/zombie-pirate-bay-tracker-fuels- chi...](https://torrentfreak.com/zombie-pirate-bay-tracker-fuels-chinese-ddos- attacks-150124/)

</comment><comment><USER8> Anyone have an idea what percentage of networks and hosting providers drop spoofed packets originating from inside their networks? What are the downsides of dropping them?

<comment><USER9> You're referring to BCP-38, aka RFC 2827. It's actually decently hard for a transit network to do this at scale. You can do it when you're a small ISP, but the administrative stuff becomes harder as you get larger and are constantly getting more allocations, buy out other ISP's, etc.

Every content network should do it. Not a huge win there, but it's something.

I'm not saying we shouldn't try, but there are countless, very long threads on NANOG about why some transit networks just can't do it.</comment></comment>


Drifty Grabs $2.6M To Turn Web Developers Into Mobile App Makers - <AUTHOR> http://techcrunch.com/2015/03/30/drifty-grabs-2-6-million-to-turn-web-developers-into-mobile-app-makers/

<comment><USER2> Congrats to you folks. I had my first Spotted Cow Wisconsin-only unfiltered beer when I stopped by your Madison offices while roadtripping the US in 2013. Awesome to see things are still going well!

</comment><comment><USER3> Has anyone used Ionic successfully? What were your thoughts?

</comment><comment><USER4> There's many of these "native ui-kits" out now. I'm hesitant to call them "apps" because they don't really allow you to interact with the device in any meaningful way. Can't write to SD cards, can't use telephony, can't use camera/nfc/etc...

If your app is simple enough that one of these frameworks will work for you, just make a web app. Why do you need a native app if you aren't doing native things?

<comment><USER5> The apps you build with these hybrid frameworks are packaged and deployed with stuff like Cordova, which exposes all (pretty much) native functionality like camera, etc.

</comment></comment><comment><USER6> What happens if Apple decides to start rejecting these JS->Native Code apps built on frameworks like React Native? Because in theory it is possible to update React Native apps remotely bypassing the App Store approval process.

2.7 Apps that download code in any way or form will be rejected

2.8 Apps that install or launch other executable code will be rejected

<comment><USER3> One clarification here. Drifty/Ionic is not native...it's "hybrid", which means it simply wrapping AngularJS into a native container.

React Native actually compiles Obj-C (much like Xamarin) which is what makes it fairly revolutionary. In other words, it would be very difficult to tell the difference between someone writing native Obj-C with someone compiling it from React Native. Drifty/Ionic is simply doing transitions, taps, using the JS engine of the phone.</comment></comment>


Mcrypt: Incorrect S-Boxes for GOST Cipher (2008) - <AUTHOR> https://sourceforge.net/p/mcrypt/bugs/35/ <comment><USER2> GOST seems like an oddball; it's been around for a long time but doesn't seem like it got any traction outside of Russia. To the best of my knowledge GOST cipher suites were never accepted into TLS, there was a draft ([http://tools.ietf.org/id/draft-chudov-cryptopro- cptls-04.htm...](http://tools.ietf.org/id/draft-chudov-cryptopro- cptls-04.html)) but it expired in June 2009. Given that it's not in TLS, isn't widely used, there aren't good reasons to use GOST over AES, and GOST is considered "deeply flawed" ([https://en.wikipedia.org/wiki/GOST_(block_cipher)#Cryptanaly...](https://en.wikipedia.org/wiki/GOST_\(block_cipher\)#Cryptanalysis_of_GOST)) I wouldn't be surprised if GOST implementations in a number of other places were equally broken.

<comment><USER3> Three reasons we sometimes see GOST (there are probably lots more; these are just the ones I'm aware of):

* It's a block cipher with a large key that was well-known in the mid-90s, when TripleDES was the best-practice.

* Its big competitor for the time, IDEA, had IP issues, so if you were looking for "natively better than DES", you might land on GOST.

* Schneier wrote about it in Applied Cryptography (blech; spit).

I think similar logic applies to why we still see RC4; when it was finally revealed, after having been an RSA, Inc trade secret for years, it was the only regularly-available stream cipher with any kind of pedigree. Since 99 times out of 100 when you're encrypting data with a computer you're really asking for a stream cipher, RC4 got a lot of use.

Obviously: don't use GOST or RC4 or TripleDES or IDEA (or Blowfish).

<comment><USER4> May I ask why you include Blowfish in the blacklist? I'm relatively new to the technical side of computers but I use Blowfish (as implemented in GPG) to encrypt my password and other files.

<comment><USER5> 1\. You shouldn't _encrypt_ passwords. [https://paragonie.com/blog/2015/08/you-wouldnt- base64-a-pass...](https://paragonie.com/blog/2015/08/you-wouldnt- base64-a-password-cryptography-decoded)

2\. Blowfish and bcrypt are totally separate, if that's what you meant.

3\. It has a 64-bit block size.

<comment><USER4> Oops I think I was a bit unclear. I encrypt my passwords file (which contains other information too, like credit card details and so on), much like how password managers like keepass do, but I do it manually with gpg set to use the blowfish cipher.

<comment><USER3> Don't use Blowfish.

<comment><USER6> What about legacy applications that rely on Blowfish? :)

<comment><USER3> Burn them.

<comment><USER6> Haha, allright then. I was recently shopping for a backup system and I guess I made the right choice when I avoided the one that made use of Blowfish.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> This is indeed pretty terrible. It indicates that this library was not adequately studied by security experts at the time it was abandoned.

If you're writing code with libmcrypt (for example, in PHP), strongly consider switching to OpenSSL or, if the upcoming RFC passes for 7.1, libsodium. (An RFC passed this week that will deprecate then remove libmcrypt support for PHP.)

Further reading:

* If you're typing MCRYPT into your PHP code, you're doing it wrong: [https://paragonie.com/blog/2015/05/if-you-re-typing-word-mcr...](https://paragonie.com/blog/2015/05/if-you-re-typing-word-mcrypt-into-your-code-you-re-doing-it-wrong)

* Mcrypt deprecation/removal RFC (accepted): [https://wiki.php.net/rfc/mcrypt-viking-funeral](https://wiki.php.net/rfc/mcrypt-viking-funeral)

* Libsodium RFC (soon): [https://wiki.php.net/rfc/libsodium](https://wiki.php.net/rfc/libsodium)

* Cryptographic Right Answers: [https://gist.github.com/tqbf/be58d2d39690c3b366ad](https://gist.github.com/tqbf/be58d2d39690c3b366ad)

(Note: Although libmcrypt is terrible, it's worth noting that PHP's own ext/mcrypt code, mostly mcrypt_create_iv(), is actually not bad.)

<comment><USER7> I'm a regular contributor to a FOSS project that supports fairly old versions of PHP.

We use defuse/php-encryption where possible, but fall back to an mcrypt wrapper on older platforms. The wrapper implements key splitting, PKCS#7 padding, HMAC, and constant-time string comparison in a way that is fully compatible with defuse/php-encryption, and we have unit tests to ensure that data encrypted with the former can be decrypted with the latter and vice versa. Still, I'm not thrilled by having to keep this wrapper around. Our next major version will finally drop support for PHP < 5.5, and I'm very much looking forward to it.

On the other hand, using OpenSSL doesn't feel all that safer, either, given its terrible codebase and frequent vulnerabilities. Can't wait for libsodium!

<comment><USER5> None of the OpenSSL vulnerabilities that were published in the past few years affected its AES implementation.

</comment></comment></comment><comment><USER8> Were there any changes since 2008 to the sources anyway?

[https://sourceforge.net/projects/mcrypt/files/](https://sourceforge.net/projects/mcrypt/files/)

<comment><USER5> Short answer: No.

Long answer: Yes, there are community-provided patches available on the SourceForge project, but they were never merged and a new release was never tagged by the project team, so effectively no.

* [https://sourceforge.net/p/mcrypt/patches/10/](https://sourceforge.net/p/mcrypt/patches/10/)

* [https://sourceforge.net/p/mcrypt/bugs/39/](https://sourceforge.net/p/mcrypt/bugs/39/)

* [https://sourceforge.net/p/mcrypt/patches/1/](https://sourceforge.net/p/mcrypt/patches/1/)

* [https://sourceforge.net/p/mcrypt/patches/6/](https://sourceforge.net/p/mcrypt/patches/6/)

</comment></comment><comment><USER9> I noticed this first on the @YOLOCrypto twitter account yesterday - [https://twitter.com/yolocrypto](https://twitter.com/yolocrypto)

</comment><comment><USER3> Don't use GOST.</comment>