infodroid

> Chrome is basically crippling Chromium's features

The article doesn't even rule out the obvious possibility that the problems are just due to a bug in Chromium, and not some malicious behaviour on the part of Chrome. After all, both Chrome and Chromium share a common code base and it's highly plausible that there might be some issues with running them side by side.

Also, part of the problem might be due to the fact the author didn't purge Chrome with `dpkg -P` but only removed the package with `dpkg -r`, leaving Chrome conffiles intact, which then broke Chromium.

So until there is at least some indication that the problem isn't just due to one or more bugs in Chromium, the author's claims are seriously exaggerated and the article is effectively clickbait.

The best way to deal with such problems is to engage with Ubuntu, Chrome, or Chromium support systems and community forums.

Why are they poor names? Both Yahoo! and Google are easy to pronounce and easy to remember.

Yesterday there was a discussion [1] about a similar app named Status, which calls itself a "Mobile Ethereum OS" [2]. And between "browser" and "OS", I'm not even sure which is the worse way to describe this type of app.

Perhaps a more constructive question would be: what is the best way to describe such apps?

[1] https://news.ycombinator.com/item?id=14161695 [2] https://wiki.status.im

Swatting is not the moral equivalent of a prank call. The psychological effects on the victim put it closer to terrorism, and the very real risk of injury, even to competent emergency responders, put it closer to assault.

There isn't any information in the article to judge whether the police response was appropriate. For example: was the victim acting suspiciously, or being violent and uncooperative during the incident? The notion that the police overreacted in this case is not a conclusion that is supported by any known facts.

The article also doesn't make the slightest attempt to examine the accusations of police incompetence that it presents, which further fuels the unwarranted sense of outrage.

Why wouldn't you have reason to ignore the warnings from people claiming to be "family" members in a hostage scenario, given they might be criminal accomplices?

Why is it bad to take reports of serious crime at face value, instead of assuming it might be a prank and risking a pattern of ignoring legitimate incidents in future?

Why would you take the expensive and time-consuming step of tracing phone calls before acting, when it risks wasting valuable time that would have saved lives in a real criminal incident?

There are incidents that demonstrate police incompetence and overreaction, or a failed law enforcement system, but this isn't one of them.

The article does a good job of deflecting blame away from the British hoaxer, which seems to be its goal. So I'm not surprised if anybody initially feels a sense of injustice here, but in this case I think it's misplaced.

> Very large projects don't have simple, easy-to-fix, outstanding issues.

This isn't generally true.

Large and well-established open source projects usually have dedicated schemes to match new contributors with simple tasks.

For example, here is the GNOME program which gets you started with some hand-picked, newcomer-friendly tasks:

https://wiki.gnome.org/Newcomers/SolveProject

Similarly, LibreOffice has the "Easy Hacks" project:

https://wiki.documentfoundation.org/Development/EasyHacks

Such portals are great for transient volunteer opportunities. But there are also open source projects with a more constant need for contributors in these different areas, and I don't think you will find them listed there. For example these are all large-ish projects that have a lot of non-code requirements and also provide support for new volunteers:

https://www.gnome.org/get-involved/

https://www.libreoffice.org/community/get-involved/

https://fedoraproject.org/wiki/Join

https://www.mozilla.org/en/contribute/

It's great to see more Haskell code being used in production.

There's no way to avoid giving away clues to "secret sauce" when releasing a driver, and keeping the source code closed doesn't change that. I don't see how the degree of accessibility is relevant.

The fact is that clues to IP can't be removed when compiling the source to binary form, because implementation details can't be hidden. So the status quo is that they are already public. Granted, it takes more skill and patience to analyze the clues in this form, but any competent hacker can do it. And the absence of names and comments in the binary makes the job harder, but doesn't actually remove the significant clues.

And while it's true that these drivers might be using licensed code, which restricts publication of its source code, this seems like a poor excuse for keeping all the code proprietary. The existence of licensed code doesn't block releasing the rest of the code. And I'm willing to bet there is an army of volunteers out there that is more than happy to write a clean room replacement for the licensed parts, if the vendor can't do it, given the opportunity.

That might be true, but the general point is that most drivers in the Linux kernel don't need blobs, and they are in many cases written by manufacturers of the hardware.

Competing manufacturers have not suffered as a result of releasing free Linux drivers, and arguably are profiting from it.

Tell that to Broadcom, Intel, Marvell, Qualcomm Atheros, and Realtek. All of them released open source Linux drivers for their wireless network products and they're still doing good business. So I don't buy this line of argument.

I don't buy it...

You can easily ship a "plain vanilla" open source GPU driver separate from the proprietary "game optimizer" code, because the former doesn't block the availability of the latter.

And if you suspect a GPU driver is cheating on a benchmark, or you have grounds to sue for IP/patent infringement, you don't need to have the source code for that. Any sufficiently motivated organization can verify that right now by disassembling the binary driver.

It is discussing this post from Alexandre Courbot: https://plus.google.com/+AlexandreCourbot/posts/BdWyfgsfp5J

As far as I know, there's nothing to stop employers from exchanging salary information directly with previous employers under quid-pro-quo agreements.

And there's nothing to stop employers from buying/renting this information from third parties, such as recruitment agencies or brokers in personal data.

All of these are arguably more reliable sources of salary information than asking the candidate directly.

> You make it sounds like it's a bad thing. Being able to focus your energies on healthy communities in a feature.

No, it's definitely a bug.

Walking away from personal conflicts weakens projects and communities through fragmentation. It feeds the selfish desire for safety and isolation at the expense of developing the more healthy ability to put aside personal differences in pursuit of a greater goal.

As a result, these so-called "healthy communities" will eventually end up more fragile and more fragmented than their original counterparts, especially since personal conflicts are inevitable in any project. What a fine way to derail a movement.

> No. It just hides them...

This is only true for toxic workplaces, but most workplaces are not toxic. There are many tech companies (large and small) that are pro-active about creating a good environment.

The chilling effect seems only true for toxic environments. Yet most workplaces are not toxic in the way that you might imagine Uber to be. There are many tech companies (large and small) that are pro-active about creating a good environment. Also, the workplace makes you think twice about bad behavior, because it has real consequences like losing your job, unlike on the internet. See also cookiecaper's comment.

Yes, there's something about the workplace that creates the sort of bonds that make you think twice before doing or saying something stupid.

If the false accusation was true then there would be a lawsuit by now. Trial by social media can never provide true justice, only an ugly exchange of accusations that harms all parties involved. That's why we should keep personal matters out of the front page of software projects.

The problem here isn't the politics, it's the mission creep. Libreboot has clear techno-political goals, to free our hardware from the shackles of BIOS and UEFI.

It wasn't created to serve as a vehicle to protest a case of alleged sexual discrimination against a friend in a different project.

There are many ways to protest at perceived injustice, but I don't think derailing a volunteer project to do that is good for the movement as a whole.

> The main difference is things tend to happen out in the open...

I don't think this is just due to a difference in the degree of openness in dealing with personal issues.

It's also the fact that project maintainers can use the project to advance their personal agenda, while a company cannot do that to the same extent.

For example, imagine if a company terminated a business partnership based only on the suspicion of sexual discrimination at the partner firm.

I think most people would find this premature or inappropriate, especially if the partner firm was not found guilty in a court, or if it did not admit any wrongdoing, and there isn't a history of such allegations at the firm.

Also, personal drama can have a negative effect on the rest of the team, and in a business environment, good HR would try to minimize that effect. But there is no such equivalent in the volunteer world.

There was the Jacob Appelbaum drama not so long ago, which was quite ugly and really seemed to drag out.

I don't know why free software projects are so dominated by personnel issues, I wish they weren't.

If that's what you call dependency hell then you've had it easy!

The story demonstrates a lack of common sense.

The author doesn't even question the dishonest and preposterous assertion from the Genius bar that the device is now worthless.

Everybody should know that there is a thriving independent repair shop industry that is more than happy to repair an old Apple laptop, even more so than a 1912 Underwood typewriter.

Except this really has nothing to do with rolling releases, or the amount of software the vendor ships in the official repositories. Switching to Debian won't solve the problem either.

There is no distro today that provides packages for all the software you will ever want, or the specific version that you need. At some point, you will resort to installing software from outside the officially-supported sources, whether from experimental or user-maintained package repositories, or from a third party in binary or source form.

Until recently, this was an operation that wasn't guaranteed to be easy or straightforward or risk-free. In the worst case, it could even screw up your system in ways that are time-consuming to diagnose and fix.

In the example you gave, I would conclude that OpenOffice didn't package their RPM well, because it ended up driving RH6 users down the rabbit hole. At the very least, they could have unpacked all the files under /opt and provided static binaries, or included all the libs in the archive. Many packages still do that today, such as Vagrant, which installs under /opt/vagrant and includes its own Ruby interpreter there.

Nowadays there are efforts underway to make installing custom software safe and easy, projects like: flatpak, OSTree, appimage, and snap. Hopefully we can reach a point where you can install whatever version of whatever software you want without breaking anything.

Debian also has an impressive reputation for quality. In many cases it has achieved, through its vast user and developer network, what Red Hat could only achieve through paid staff and commercial resources.

But this is not true in all areas, especially in some aspects that matter to companies such as training/certification and having good up-to-date documentation.

And as a volunteer-driven project, I don't think Debian can ever be as responsive to end-user problems or requirements as a commercial product can be.

But it definitely gives Red Hat a good run for its money. For example, the Debian LAMP stack has long been and still is the gold standard.

UNIX vendors didn't normally ship releases or updates that introduced dependency issues. Part of their job was doing testing and quality assurance, that's what you were paying good money for. Most such issues were introduced locally.

A good sysadmin would know how to avoid dependency hell. For example this might include taking basic precautions such as testing changes in a chroot or development/testing environment, before rolling them out.

I'm not saying the problem didn't exist, only that it wasn't an actual problem if you knew what you were doing.

Have you considered the possibility that your poor experience with Red Hat was due to the fact you were new to Linux?

Encountering dependency hell is usually a sign that you don't know what you're doing.

Red Hat "just works" and has always enjoyed the reputation of being the most bulletproof distro if you could afford it.

...or also because it has a removable battery, a trackpoint and multimedia keys, video and ethernet ports and a docking adapter, and venting to run with the cover closed without overheating.