Renaming Iceweasel to Firefox
bugs.debian.org
bugs.debian.org
This is great news for few of us.
But it has been hard to read trough this comments and realize how much ignorance about what Debian is, how it works, what the Debian bug tracker is, what a voluntary-based project is, and to read some assertions and prepotency around in HN
If you see ANYTHING wrong with Debian, go fix it, or shut up and go to sell your stuff to another one.
Debian is not a startup. Debian is not an elastic architecture in the cloud to support/pay-for traffic peaks. Debian may benefit from your solutions and resources, if you're so good. Debian isn't perfect.
The Debian bugtracker maybe not the web application I could write in 2016, but I'm conscious on how much work has been around it, and it's ecosystem, how much I'm in debt with the Debian bug tracker as opensource user, and how much should I THANK to the people who did work on it, who works on it and who uses it, and even translates it
Depressing to sometimes find great threads, and sometimes loose the time with subjective views, inexperienced reviews, false and incomplete assertions, haters, and mass style thinking.
I'm scared to imagine on hands of what kind of people there are technological choices... or to think that people gets influenced by content creators of this level... maybe I'm lucky and most of those opinions I dislike, are not from real engineers/hackers, but from lost re-users, and people without humility repeating what they find shocking, like a child of 3 years.
Feel free to downvote without reasoning why.
Are you really saying that the only way to contribute to Debian's success is to directly fix problems yourself? Community feedback (in the form of bug reports, comments on forums, mailing list discussion participation, etc) is hugely important in most every open source project; dismissing that is foolish at best and harmful at worst.
"Talk about the problem, where you can fix it, not just a comment in a third party forum".
I was after a telephone discussion and maybe I was a little bit harsh.
It's not that bug reports are not useful, it's that if you follow the debian manual, you don't need the web interface for reporting bugs...
People working on web technologies, use to blame opensource projects a lot, without any help.
I have half a mind to just add this to every single project's README in the https://github.com/redis-store organization.
May I suggest using "$PROJECT may benefit from your solutions and resources. $PROJECT isn't perfect." - "if you're so good" could be interpreted as "if you're good enough".
Happy that my keyboard rage was inspiring for something :)
Ok, so Debian is a developers-only distribution?
> Feel free to downvote without reasoning why.
I didn't bother, but "Please don't bait other users by inviting them to downvote you or announce that you expect to get downvoted." https://news.ycombinator.com/newsguidelines.html
For all practical purposes, I'd say yes. GNU/Linux as a PC operating system for non-programmers is a lost cause. Sure, some organizations make it work, but it probably requires a lot of technical support; they'd probably be better off using Android tablets and/or Chromebooks if they need something less expensive than a Windows PC, let alone a Mac. And when non-programmers need web hosting, they don't reach for a DigitalOcean droplet; they use a shared host that offers an abstraction over the LAMP stack like cPanel, or an even more non-developer-friendly service like Squarespace.
Engineering workstations. Lots of them.
This might not be a bad characterization of where it sits now.
If you want a hand-holding "user-friendly" (and I use the term advisedly, based on the common, flawed conception of what a "user" is), create one based on Debian, leveraging the Debian tools and packages and processes to make an Ubuntu or Mint or something else.
Debian isn't a meta-distribution. It is a distribution in its own right. However, it is commonly used as the foundation for a different distribution, with different goals and different ways of relating to the world. Debian itself remains unchanged, ready to base another distribution off of, and another, and another...
http://www.elivecd.org/ - The latest release is always based on Debian Stable and is currently under active development. The whole system is changed in (mostly subtle) ways to make it more attractive to a new Linux user. This is Debian, with some additions. I push this to any friends who say they are interested in Linux, but maybe just want to try it first.
I would not recommend Ubuntu to a new user (unless they were my employee, we use it at work) or Mint for that matter. I would not recommend Debian in spite of using it myself at home, because I don't always want to be the Debian support guy, or have to be the one to say RTFM. Elive tries to be as self-explanatory as possible, even in its somewhat Tarzanic way.
Well, as an user of a openly licensed system, you are free to use the source. As well as, you're free to don't use it :)
But regarding voluntary work, it's useless and ugly to harm and bash it, without helping the cause.
Didn't know that guidelines, thanks, and sorry.
Absolutely not. You can use Debian and help improve Debian without being a developer and even without being very technical.
I fully understand the need for all the process and policy but it can be very difficult to get things fixed in Debian without talking to the right people or attending the right conferences.
I didn't mean it's the only and single way to change something in Debian... the subtle of my message was, that complaining outside the project, does not help to anybody, and forms subjective opinions on persons that didn't have them.
Today, someone at $work that never did write perl, was complaining on perl and Larry Wall just for laughs, I told him: when Mr Google calls you to speak about _your_ language, when the world is full of mirrors of libraries written by all kind of persons and companies for _you_ language, please, come back, and we have some laughs.
It seems that some people needs to "attack third parties together" to feel "in society".
I dunno, I'm pretty sure that this is a form of the "appeal to authority" logical fallacy - i.e. person X has achieved less than person Y, therefore their opinion is invalid. Perl has problems like any language has problems, but sometimes it's the right tool for the job.
I know the kind of person who derides languages for whatever reason - sometimes I am that person. It's fun to bash PHP, C#, Java, Ruby, Perl, Python, even Shakespeare Programming Language [1] but at the end of the day they're a means to an end, not an end to themselves.
Some comments at Linux.conf.au recently made me aware of platform/language shaming. It's not a good thing and I'm working to stop doing it.
1: http://shakespearelang.sourceforge.net/report/shakespeare/
\ VB6 can bugger off
Users use computers to compute - "using linux" is not a primary task. I'm not saying open source should compromise on their core values, but Debian could stand to take a page out of, say, the Tor Project's book and focus harder on usability.
And I don't mean that metaphorically. Ubuntu literally is Debian with usability enhancements.
Debian is an amazing project that is where it is because so many people decided to "go fix it." Not everybody who uses Debian needs to have that mentality, but anybody on HN who is complaining about the project and wants to see it improved should consider translating that opinion into action.
This isn't to say that txutxu worded his response in the most tactful manner, of course, but you have to consider it in context.
One of the fun differences between the various organizations I've worked for is the differing ideas of how frequently releases should happen and what is considered "fast" and "slow" in different places. I've seen release cycles measured in weeks and those measured in years. I'm sure there are places that release every N days. How people get used to some particular cadence and start believing that it's the only proper (or possible) way! One of the achievements I'm most proud of is helping a group make a difficult transition from a long, irregular cadence to a fast, predictable one. Going from a release process of "Release when company leadership subjectively thinks it's ready" to "Release every 4 weeks on the day" can at first rattle some people who are attached to The Way We've Always Done It, and it requires more discipline in terms of development practices, testing, feature creep, etc. But it can be done!
Not saying a faster or slower cycle is needed for Debian or Mozilla (it would depend on a huge number of factors), but your release cadence shouldn't be considered some immovable law of nature.
I agree, but I think it mostly depends on the product. If you have a bulletproof software implementation of, say, a finances managing system, then you will rarely need to update it -- as long as it has no bugs then the users will be happy with it.
On the flip side, if you have a program that has to be both secure, but also have a lot of features, and is used by a lot of people, then I think you will find yourself releasing every few days -- even if you just stick to staying on top of any vulnerabilities and bugs that could occur.
So you end up with two main releases for the browser, one is the standard one that updates every six weeks, and the other has a more stable 'extended support' environment that just gets bugfixes, for places that can't easily deal with changes very often (like a business or education SOE). Debian stable usually lasts for about two years, and modern browser releases would find that impossible to support.
But I always get people looking over my shoulder and asking "what the heck is 'iceweasel'. To which I explain the whole issue of Debian was distributing a patched version of Firefox with their OS back in ~2007 era and Mozilla, for trademark reasons, said you can't modify the browser and still distribute it with the official logos and name. Which lead to Iceweasel... but then a few years later Mozilla changed the license terms so now I guess here we are....
Note that testing doesn't get the same level of security support as stable: "Compared to stable and unstable, next-stable testing has the worst security update speed. Don't prefer testing if security is a concern." [1]; more details: [2], [3], [4].
[1] https://wiki.debian.org/DebianTesting#Considerations
[2] https://wiki.debian.org/Status/Testing
https://bugs.debian.org/725934
To speed it up even more you would need to follow the unstable/testing pages on the security tracker and file bugs to get maintainers to do fixes and do NMUs when maintainers are on vacation or missing.
https://security-tracker.debian.org/tracker/status/release/u... https://security-tracker.debian.org/tracker/status/release/t...
If you are using the Mozilla Mark(s) for the unaltered binaries you
are distributing, you may not charge for that product.
That is, it is entirely legitimate and legal for me to make a Debian derivative where the only means of distribution is that I charge you $30/month for a CD of my distribution (including source to any patches I apply), and I don't distribute it otherwise. I just have to give you the right to rip the CD and put it online for free, if you so choose.
The only thing I can't do is to say, the CD for AwesomeDebianFork 1.0 binaries is $9 and the CD for AwesomeDebianFork 1.0 sources is $90. (The GPL would reject this as not being "reasonable"; the DFSG would reject this outright for violating #2, "The program must include source code".)
Ah, yeah, that was an aspect of my original comment I wasn't thinking of, but was implying, and I had glossed over that in your reply. Thanks for correcting me and clarifying. :)
Also, Debian is really lacking some more modern bug management / issue tracking system.
It might be useful to provide e-mail interface for it, but I fail to see why it also can't be managed from some site at the same time instead of limiting it to read only view.
Is there a good open-source GitHub alternative that implements this feature?
I know of no particular opt-out feature, though at least for OTRS it would be rather easy to write an add-on that makes you watch all new tickets in a particular queue, of which you could opt-out by stopping to watch a ticket.
What do you mean by that? Doesn't every bug tracker implement that feature?
I understand some people prefer email for following up on these things, but destroying my inbox by following a busy project is not something I'll ever do. GitHub's default is to notify project owners, issues you've participated in or actively followed, or those you're mentioned in. I think that's fair.
You can also "one click unsubscribe" to them at any time, which is great.
Others I've been subjected to are things that are barely more than mailing lists. I have no idea how people deal with these.
By the way, something happened to the fonts on that site a few day ago. They look worse now.
Then change your release cycle. Seriously, it's not that hard. Say that browsers are different and get released frequently. Create a firefox-lts package that is updated at the beginning of your Debian release cycle -- and never again. Let the firefox package be the firefox package, updated as frequently as upstream wants.
Debian's update system does drive me nuts, but I have never run a Debian server for longer then 6 months.
So if you have a vanilla config on Apache it still works.
(For the more adventurous desktop users, they can also use Debian unstable for the frequent releases. Unstable isn't unstable in terms of your machine falling over. Rather, there is a lot of package churn, and you need to use something like "sudo aptitude upgrade --visual-preview" when upgrading to ensure that you don't try to upgrade something in the middle of a big package transition before everything is finished and ready in the package repo.)
For a Linux distro that has been around so long, it's mind boggling they still don't understand that. Wine used to have the same problem - Wine's cycle had the Chrome-like cycle before Chrome even existed. Release every 2 weeks like clockwork. Releases are not any more or less stable than the previous one, but they implement more functionality and a newer release will almost always be better than an older one. Wine's "Stable" releases are meaningless, other than "We spend a month working on bugfixes/regression instead of features before a stable release".
Which means exciting new regressions every two weeks! When I used wine it was definitely the case that certain applications(games) worked better with specific wine versions so a continuous release cycle could result in breaking a working application. That's something users of stable are trying to avoid.
If a user wants the latest version of a package you can always install it manually.
Yes, its semantics whether you just pin arbitrary releases and call them LTS vs having dedicated versioning schema to support it, but you called it a Chrome like cycle, when its just a more general constant iteration with occasional LTS cycle. Not many products actually use the full blown constant iteration for everyone model Google uses on Chrome.
[1] We even have an explicit regression tracker that places blame and shame on whoever broke it! http://source.winehq.org/regressions
The purpose is not to get a stable release of each upstream project and build a release from those. The goal is to get any release of each upstream project, test it for a few months to ensure there are no show-stopping bugs and to document the known ones, and then freeze it.
The goal is not to ensure lack of bugs, it's to ensure stability, that is, that no new bugs appear or existing behaviours change.
The goal is to allow the sysadmin to configure the system, test it - working around existing bugs - and leave it running, being reasonably sure that stuff won't randomly break until he upgrades the major version, while remaining secure.
I used to do triaging for Wine and I can't tell you how depressing that was, the amount of time wasted by these distro policies.
And our stable branch is changing to yearly releases! We are going to do a code freeze every Fall and release in late Fall or early Winter. It is also going to receive more regular backports of "safe" improvements, so slow distros like Debian can benefit from important fixes. We've already had a dot-dot stable release this year!
http://source.winehq.org/git/wine.git/shortlog/refs/heads/st...
They definitely do understand that - they also offer more packages than any other x86 operating system. It's just that they have a reason for doing it their way. The operating system is meant to provide a stable base, and the user can then select particular software for more frequent upgrades by adding their own target repositories. Or using make.
Debian is one of the two major linux distros that other distros source from. It's a bit weird to suggest that they don't really get how software is developed.
As in, they accept and release new versions from upstream instead of maintaining their own fork with backports.
Debian stable is "conservative and with as few changes as possible", so the ESRs are the obvious choice for it.
Please be considerate when linking to webapps. If there's a static or cached version available, please post that.
In this case Debian's tracker mirrors everything to publicly mirrored mail servers (which are static), ie: https://www.mail-archive.com/debian-bugs-dist@lists.debian.o...
The last I’ve heard was that debbugs is run on the fastest hardware the Debian project has available, i.e. one of the few machines with fast SSDs.
Come on man.
Classical Linux userland devs (I count myself among them) had a tradition of dissing web development as "not real software development". I also do web development, and it seems Debian could benefit from ditching that mentality and encouraging a volunteer (or using some well-spent funds) to make their bug tracker safe for the 2016 web. All it probably needs is a caching proxy.
Debian should definitely do more to stop this from happening but this isn't the first time a HN link to a clunky old webapp has taken it down.
EDIT: I wasn't joking around, people. Don't you find the etymology of such colorful phrasing to be interesting?
> Perhaps I'm being unfair
...
> Debian should definitely do more to stop this from
> happening but this isn't the first time a HN link
> to a clunky old webapp has taken it down.
I haven't but I'm also not ungrateful and complaining about it.
You may be able to spot a 90's style perl-based web app but some of us are much younger and in a different field than web development.
I don't think it's worth shaming OP and HN for using the Internet as intended. The real problem seems to be that Debian is using outdated technology for their bug tracker.
Given that we're quite a technical group of people and this was a submission about something that is even more populated by technical people I just expected a little more common sense.
And no, this isn't just to help Debian. When you share a link and inadvertently kill off their server the people trying to read the story you shared suffer too.
Linking to static stuff is better for everybody.
> I just expect a little more common sense
I understand where you're coming from. But, speaking personally, everything you said was news to me. This field is more diverse than you suggest. You might want to consider we're not all Linux users and we're not all web developers or administrators.
Even if we have us experiences in those areas in th past, maybe it's been a while. Maybe we're tired and not thinking straight. Maybe it's not our problem so we're not even thinking about it? The point is, you're expecting too much from people.
> Linking to static suff is better for everybody
So I still think scolding users is an ineffective way to solve an infrastructure problem. I can't imagine a scenario where that would work out successfully.
https://webcache.googleusercontent.com/search?q=cache:PtAvYw...
Nothing stops you from getting Firefox on Debian the "Windows" way.
The official Linux x86_64 build for version 44.0.2 is here:
https://ftp.mozilla.org/pub/firefox/releases/44.0.2/linux-x8...
I don't know who uses those builds, though. We can be sure that the year of Linux on the desktop will never arrive if we expect end-users to unpack tarballs.
Edit: To make that last part a little more constructive, perhaps this will help with distro-agnostic packaging of official Linux builds of Firefox and other applications: https://wiki.gnome.org/Projects/SandboxedApps
2. Run.
It is quite bad. External dependencies are also nearly impractical this way, so all installers tend to embed their universe of dependencies, making for an even worse experience.
And maybe people include way too many dependencies in their projects if it's too much to manage manually. Also, installers are perfectly capable of managing dependencies.
Prove it.
The package manager allows you to cryptographically verify the binary was inspected by somebody you trust (the package maintainers). While windows has added code-signing/verification capabilities, many installers are unsigned, and those which are signed don't have a useful trust anchor.
A new upload creates an audit trail that could be checked if needed.
Have you ever tried writing a Windows installer?
Some of the installers tried to install bundled crapware - which is frequent in the Windows world, and you have to watch out for it with every installer.
I hadn't done any real work on Windows for so long that I'd forgotten the whole "is this even safe to download?" problem that Windows has with it's applications.
I'm not all that experienced in cleaning windows machines these days, but I do remember that each of the tools I ran cleared out something beyond just 'tracking cookies' - and each of them got something that the others didn't.
I certainly feel for mere mortals that have to do this sort of stuff on their own, given that the anti-malware websites frequently have the same garish in-your-face appearance and crappy download sites as malware-supply websites do.
> Why does the operating system have any say on what applications get released
> and how often?
1. I, Steve, write some bit of software, libfoo, and host it on my GitHub page.
2. Debian users would like to use libfoo. They have two options at this point: download and build libfoo from me, or get it from Debian's package repository.
3. In order to be put into Debian's repository, a suitable package needs to be created. What exactly that means depends on the package itself, but sometimes it's about things like "which paths are searched by default". Anything that integrates with the overall system. So someone, probably not even me, would need to say "I'm going to maintain a package for libfoo in Debian." They are responsible for taking from "upstream", my GitHub page, and producing a .deb for inclusion in Debian's repositories. This may involve modifying libfoo in some ways. It depends.
At any time, a user of Debian can choose: Do I get libfoo from Steve's GitHub, or do I get libfoo from apt? The reason that you might choose the latter is because Debian knows Debian better than I do. (Well, I said I use Debian above, but this works across distros, basically. I have no clue what Fedora's norms are, for example.) The package from Debian's repositories will be better integrated into the system, and will be tested for compatibility with other packages. Part of this is due to the release cycle of Debian itself; and this is what's being discussed here. It's not about when Firefox is released, it's about when the Debian package for Firefox is released. And what version of that package corresponds to which upstream version?
So! Back to this bug. Due to some... history between Mozilla and Debian, Debian's package for Firefox couldn't be called "Firefox." So it was rebranded to "Iceweasel." This bug is about re-synching the names, and having the Debian-provided package produce "Firefox" again.
Does that make sense?
It has problems like anything else does, but it's pretty effective overall.
What specifically do you find bad about it?
Any better ideas than these two?
Because it's a curated experience. But debian (or any distro) don't force you to use their versions. You're quite able to install your own on your free, open source software. Find your own repositories, set up your own repositories, manually install downloaded packages, configure/make/make-install your own software... debian not only doesn't stop you from doing this, but is built around letting you do this (as are all major distros).
You're not forced to use a repository at all.
No. Debian GNU/Linux is an operating system (specifically a variant of GNU/Linux). Linux is a kernel, not an operating system (I think only Linus tries to claim that a kernel is all that makes an operating system -- but I'd require at least libc and POSIX coreutils before you can begin to call something an operating system).