Renaming Iceweasel to Firefox(bugs.debian.org)
bugs.debian.org
Renaming Iceweasel to Firefox
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006
11 comments
The problem with "you can go fix it if you want" is that the barrier to "fixing it" is very high, even with such great things as #debian-mentors.
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 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.
Agreed, what you can do on first contact, is not always what you would like to do.
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 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".
>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.
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
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
As a usability expert, I can tell you that: "If you see ANYTHING wrong with Debian, go fix it, or shut up and go to sell your stuff to another one." is why it will NEVER be the year of Debian on the desktop.
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.
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.
Keep in mind the target audience of txutxu's post: this is Hacker News! His reply is to a group of people who are, if not all experts in technology related fields, likely capable of contributing to the Debian project in some meaningful way.
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.
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.
There already is a usability focused Debian. It's called "Ubuntu".
And I don't mean that metaphorically. Ubuntu literally is Debian with usability enhancements.
And I don't mean that metaphorically. Ubuntu literally is Debian with usability enhancements.
> If you see ANYTHING wrong with Debian, go fix it, or shut up and go to sell your stuff to another one.
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.
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.
well, I suppose my point there was:
"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.
"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.
"$PROJECT is not a startup. $PROJECT is not an elastic architecture in the cloud to support/pay-for traffic peaks. $PROJECT may benefit from your solutions and resources, if you're so good. $PROJECT isn't perfect."
I have half a mind to just add this to every single project's README in the https://github.com/redis-store organization.
I have half a mind to just add this to every single project's README in the https://github.com/redis-store organization.
>$PROJECT may benefit from your solutions and resources, if you're so good. $PROJECT isn't perfect.
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".
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".
When I did arrive to the post I was on bad mod by other reasons, the modification that voltagex_ suggests is totally right.
Happy that my keyboard rage was inspiring for something :)
Happy that my keyboard rage was inspiring for something :)
> If you see ANYTHING wrong with Debian, go fix it, or shut up and go to sell your stuff to another one.
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
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
> Ok, so Debian is a developers-only distribution?
Absolutely not. You can use Debian and help improve Debian without being a developer and even without being very technical.
https://www.debian.org/intro/help
Absolutely not. You can use Debian and help improve Debian without being a developer and even without being very technical.
https://www.debian.org/intro/help
> Ok, so Debian is a developers-only distribution?
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...
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...
For a plug of my friend Thanatermesis' great Debian-based distribution, which recognizes the distro and free-software ethos is not always fully conducive to a positive user experience at the forefront...
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.
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.
> Ok, so Debian is a developers-only distribution?
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.
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.
> Ok, so Debian is a developers-only distribution?
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.
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.
> Mozilla releases new Firefox releases every 6 to 8 weeks.
In parallel of these rapid releases [...]
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.
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 find it very interesting that they are adopting a different release schedule for Firefox than the rest of Debian stable. People that care about fast release cycles probably really just care about few minor things being up to date, while administrators don't care about which programs/libraries make problems when updating as long as the total amount of breakages in a certain time isn't too high.
This is probably due to the specific nature of browser upgrades, which is the reason why firefox and chrome went to 6-week autoupgrade schedules for clients: people expect a hell of a lot from their browsers; troubleshooting a fractured version environment in such a complex field is next to impossible; important security updates need to be pushed.
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.
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 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.
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.
Even if you are adding features, some software products are such that customers simply can't/won't upgrade at a pace of more than a few times a year (if that). Anything mission critical will need to go through validation, acceptance testing, you'll want to check that integrations with other products are unaffected, etc. Especially if the organization is understaffed in the IT department, then these sorts of upgrades can easily lose priority to the 100 other things on their plates.
Funny, I've been running Debian since 2007. I mainly got hooked on their 'testing' branch since it is just "always up to date".
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....
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....
> I mainly got hooked on their 'testing' branch since it is just "always up to date".
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
[3] https://www.debian.org/security/faq#testing
[4] http://secure-testing-master.debian.net/
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
[3] https://www.debian.org/security/faq#testing
[4] http://secure-testing-master.debian.net/
You can slightly speed it up by using apt pinning to get security updates from Debian unstable (but other packages from testing) when available.
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...
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...
A few years ago some extensions wouldn't work with iceweasel. I forget which ones, and why, but it basically boiled down to: "this extension is meant for firefox". I wish I could remember which ones those were to see if it really was just a naming issue.
It's interesting that the Paul brings up the trademark license clause regarding for-pay distribution.
If you are using the Mozilla Mark(s) for the unaltered binaries you
are distributing, you may not charge for that product.
Ahhhhhh, I've always wondered about clauses like that with the distribution of software compilations. For example, I can buy a Debian boxed set from here: http://www.jbox.ca/product-category/computers-tablets/softwa... or any of the other distributors: https://www.debian.org/CD/vendors/. I think a clause like that would prevent them from selling those.
I'm fairly sure when you are buying physical copies of Linux distributions you are buying the service of compiling and copying it and providing physical media, the box, any manuals, etc. The source code at a minimum must be made freely available to others. That is, they aren't charging for the code delivered, but the delivery itself and the physical media.
You're permitted (under both the GPL and the DFSG) to restrict who you make the code available to, and to charge them for it. The only requirement is that the recipient have the right to further redistribute the sources, without being compelled to restrict who they distribute it to, or being compelled to charge for it.
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.
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.
I'm not sure if this is meant to imply they don't have to offer the source in some form or just a clarification of my prior comment, but I think it's pretty clear from GPL 3.0 section 6[1] that it is required, and the most recompense you can get from this is "for a price no more than your reasonable cost of physically performing this conveying of source", as if it's network accessible it must be free. So, at least part of my prior comment was incorrect, you do not need to provide it free of charge, but the only charge you can require, and then only for providing it on a durable physical medium, is the reasonable cost of doing so.
1: http://www.gnu.org/licenses/gpl-3.0.en.html
1: http://www.gnu.org/licenses/gpl-3.0.en.html
Well, you can charge for the software as a whole, which I read your comment to claim you can't. I can absolutely say, hey, here's AwesomeDebianFork 1.0 with some custom patches on GPL code, you can get a CD set of binaries + source for $99. I don't have to resort to circumlocutions about service, and I don't have to make the source available to anyone else. (You are free to copy that source CD, though.)
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".)
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".)
> Well, you can charge for the software as a whole, which I read your comment to claim you can't.
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. :)
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. :)
[deleted]
When included in a larger work it would seem that you can argue you are charging for everything else and providing Firefox for free kind of like Microsoft and IE.
As long as Debian is altering the binaries this clause does not apply.
Related: https://bugzilla.mozilla.org/show_bug.cgi?id=555935
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.
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.
Although GitHub Issues has a lot of issues, for the singular reason that you can opt-in and opt-out of notifications on particular subjects I find it vastly more useful than most bug trackers.
Is there a good open-source GitHub alternative that implements this feature?
Is there a good open-source GitHub alternative that implements this feature?
> you can opt-in and opt-out of notifications on particular subjects
What do you mean by that? Doesn't every bug tracker implement that feature?
What do you mean by that? Doesn't every bug tracker implement that feature?
The ones I've used in the past relentlessly spam you about every little thing for every issue or tell you nothing about anything. There's very little in the way of fine-grained control.
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.
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.
You can (un)subscribe to specific issues, but you cannot filter issues in general. Which means you'll still get notified about new issues until you manually (or programmatically) unsubscribe from them.
OTRS and RT allow you to watch a ticket. Thus you can chose to be notified for changes to a ticket (opt-in).
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.
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.
Gitlab?
https://tracker.debian.org/pkg/iceweasel is getting there. The bug tracker has lots of integration with other Debian systems. I'd say it'd be a huge project to upgrade/replace.
Interesting, thanks. I'm using that tracker site quite often to see progress of various packages. But I didn't know it will be useful for managing bugs as well.
By the way, something happened to the fonts on that site a few day ago. They look worse now.
By the way, something happened to the fonts on that site a few day ago. They look worse now.
I don't think you'll be able to manage bugs from it directly any time soon, but it was an example of a "better" interface for Debian services.
> On the contrary, Debian having a longer release cycle (about every two
years), release cycles don't align.
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.
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.
This is already kind of the case. Debian stable tracks the Firefox ESR releases, updating when a new one comes out. If you want the Firefox frequent releases, you get them with backports from the Debian Mozilla team (out of the main archive).
(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 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.)
If you don't like the 2 year release cycle, use Ubuntu, which is Debian-based. Debian maintains such long release cycles because the tolerance for bugs and incompatibilities are smaller than other linux distros. For long-lived applications or applications that have long planning periods Debian is ideal. NASA uses Debian, because their projects are measured in years, have low tolerances for bugs, and are developed to last 5+ years. Simply put, Debian's release model is for a different use-case than your typical web development project
It's really very nice to just throw Ubuntu 14.04 on everything and not worry about it. I can use my machines for doing work and not have to waste a lot of time dealing with whatever the latest churn is.
Debian has both: I use Stable on my servers and Unstable/Sid (which is a rolling-release distro) on my laptop.
There is also Debian testing which is more polished than Sid, but is also semi-rolling.
[deleted](1)
What does this have to do with Firefox? Is NASA writing rovers as Web apps? If not what does it matter which version of Firefox is installed?
User experience stability is often a real problem in the corporate or institutional world. Keeping a maximally stable version of Firefox will help corporate users a lot - it's not even necessarily about stability as much as it's about user retraining, in-house extensions, etc.
For most companies what version of firefox probably doesn't matter. However, there are tons of legacy desktop apps in government, call centers etc where installing a new version of firefox will break the application. Hell, the callcenter my company uses an app that will only work with certain versions of ie. The company that made the app went out of business years ago and the only thing the call center has is a binary they install on all desktops.
Literally right below that it says: "To address this packaging issue, once a ESR cycle is over, Debian has
been accepting uploads of new ESR releases in the stable release."
As in, they accept and release new versions from upstream instead of maintaining their own fork with backports.
As in, they accept and release new versions from upstream instead of maintaining their own fork with backports.
But most users don't want the ESR version, they want the latest non-ESR version, yes, you can go and get it from mozilla but some users find this inconvenient.
Then they can get it from outside the stable branch. Testing and unstable both have a Iceweasel 44, and there is the mozilla repository at http://mozilla.debian.net/ just for mozilla software.
Debian stable is "conservative and with as few changes as possible", so the ESRs are the obvious choice for it.
Debian stable is "conservative and with as few changes as possible", so the ESRs are the obvious choice for it.
Debian implements the comical definition of Bureaucracy really well. Missing the forest for the trees and thinking that every single piece of software is built and released the same way.
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".
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".
I think this is a misunderstanding of the goals of Debian Stable.
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.
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.
The problem then is when this trickles down to projects like Ubuntu. For years, Ubuntu (the desktop distro) had Wine 1.0 as its only version of Wine, when there were something like 40 new development releases of it already available. This caused hundreds upon hundreds of bug reports and user frustrations for no good reason - issues were already fixed in most recent versions of Wine.
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.
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.
> Release every 2 weeks like clockwork.
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.
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.
I don't disagree with anything you said, but I would like to add that if you become aware of a program that used to work, but no longer does, PLEASE file a bug! We take regressions very seriously[1]. There are often reasons they can't be fixed immediately, but more often we can fix it quickly. But we have to know about it first!
[1] We even have an explicit regression tracker that places blame and shame on whoever broke it! http://source.winehq.org/regressions
[1] We even have an explicit regression tracker that places blame and shame on whoever broke it! http://source.winehq.org/regressions
I'd love to report more stuff in Wine but isn't there a requirement to be running the latest/dev branch? This is tricky to do in Debian (because I prefer to build debs of whatever and then install those).
You will be asked to test it in the latest release, yes, but perhaps someone else can test it for you, or at least get developer eyes on the issue. In any case, it's unlikely to be just closed invalid without any consideration. We would rather know about it than not.
Parent is actually wrong - Wine releases with the Gnome cycle, where even releases are stable and odd ones are unstable. Debian should technically be shipping both versions according to upstream release cadences - people who want stable use 1.8 right now, and people who want latest features use 1.9.
In what way am I wrong? Wine releases are in fact every two weeks with a stable release once in a while. How is it relevant that stable are even and unstable are odd?
Because Wine (and Gnome) maintain them in parallel. With Chrome you have the one release version that gets constantly updated every two weeks, but unlike Firefox's ESR / Linux's LTS kernels Google doesn't want to maintain an "LTS" version of Chrome.
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.
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.
We still release every 2 weeks on the dot. Next release is on Friday.
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...
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...
> For a Linux distro that has been around so long, it's mind boggling they still don't understand that.*
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.
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.
It's a bit sad to see "real" distributions have shrunk to 2. In a way, you can say that's more of a case of these growing while everyone else did not (see: Slackware), and that it's a net positive in terms of consistency, but it might also indicate a retreat from experimental approaches. "Different" distributions like Gentoo failed to capitalize on early momentum, and there is now a general expectation that all * nix systems should look like RH or Debian.
Surprisingly, Chromium is always up to date on the Debian stable release. Why can't they do the same for Iceweasel/Firefox? keep the ESR version and a version that matches upstream latest releases, but there's probably something I'm missing here.
They do the same for Iceweasel: stable gets updated to the ESR x release around when version x.0.1 gets out.
[deleted]
$deity no, then I'd have to rebuild servers every year instead every two/three :/
I have been just doing dup on OpenSUSE for over 6 years without a single issue. :) I am getting rusty on rebuilding server skills.
Debian's update system does drive me nuts, but I have never run a Debian server for longer then 6 months.
Debian's update system does drive me nuts, but I have never run a Debian server for longer then 6 months.
Considering the last distro upgrade had Apache going from 2.2 to 2.4, which introduced considerable changes to the config file format, "upgrading the servers" is not something that can be done in _all_ cases.
But that is an issue with Apache and not really a Distro issue. I'm thinking I didn't have to change anything on my Apache config since mine is very vanilla.
So if you have a vanilla config on Apache it still works.
So if you have a vanilla config on Apache it still works.
I keep finding it puzzling that Debian would opt to maintain a fork of Firefox, while at the same time go all in with systemd because it would be too much effort to maintain something else.
Congratulations HN, OP, we DDoSed the debian bug tracker.
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/[email protected]...
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/[email protected]...
Or write faster apps? Caching pages for logged-out users is part of web site performance 101.
Debbugs works great for being last updated 12 years ago. It's main interface is email, after all, so the web interface is read-only. I think the real issue here is the hardware it's running on.
Forking a new process to run a Perl CGI script for every request is going to be far from optimal on any hardware.
With regards to hardware being the issue:
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.
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.
Right so even if your application is only meant for 10 concurrent users it's your duty to optimize it to the point where it can handle HN traffic...
Come on man.
Come on man.
The reality we live in today is one in which traffic spikes come without warning, whether from sudden media attention or DDoS. One of the core features of the web is the ability to link to web sites. If a service can't handle traffic, it shouldn't be accessible from the open Internet, least of all if it's a service run by a major Linux distribution.
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.
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.
I'm not familiar with whatever bug tracker they use, but shouldn't this be the default such that a user doesn't have to make this mental note?
Perhaps I'm being unfair —because I know how the sausage is made— but if it looks like it's generated by Perl (clunky late-90s design, obvious interactive parts, filter, logins, etc) it probably scales like a squirrel carrying watermelons. (One at a time is okay.)
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.
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'm going to have to ask: is "scales like a squirrel carrying watermelons" your own material, or is that a saying invented somewhere else? The imagery is just so apt, the etymology of the phrase is suddenly piquing my curiosity.
EDIT: I wasn't joking around, people. Don't you find the etymology of such colorful phrasing to be interesting?
EDIT: I wasn't joking around, people. Don't you find the etymology of such colorful phrasing to be interesting?
I believe it's original. I can see the garden between my monitors and could see a squirrel at the time. They weren't carrying a watermelon at the time but I was just trying to think of something they could just about manage one of.
The bug tracker has basically one maintainer who is quite busy with other stuff. This is the case for a lot of Debian infrastructure unfortunately. Unfortunately maintaining services isn't a particularly well-staffed job, especially for older services.
I fail to understand how the burden of a clunky outdated web app should be the end users problem.
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.
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.
Using the Internet as intended? You're making an assumption that every webserver is intended to be swamped by a load of people who have very little interest in (here) discussing or fixing a bug. That's what the webapp here is for.
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.
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 made no such assumption. I made a standalone claim. Sharing a link is using the Internet as intended. There are no assumptions needed.
> 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.
> 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.
> 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.
HN should just do this by default; meaning if traffic gets results in a site response time dropping, it should know that that Google cache or the like is up, or provide a cache itself.
No one expects their link to go viral. If the link is down there should be a way to propose a mirror.
I had exactly the same thought...
Doesn't look to be responding. Mirror:
https://webcache.googleusercontent.com/search?q=cache:PtAvYw...
https://webcache.googleusercontent.com/search?q=cache:PtAvYw...
That's disappointing; the article mentions that Mozilla is happy with Debian's patch set, but I don't think they'd be happy with a patch that disabled mandatory extension signing. I was looking forward to Iceweasel sparing us from that anti-user nonsense.
[deleted]
I don't understand why Debian has anything to do with Firefox. Why does the operating system have any say on what applications get released and how often? Isn't this the whole point of using free, open source software? To be able to choose your own components? Why do we need Debian bundling Firefox?
Debian user and Mozilla employee who uses Iceweasel here. I work on Rust, not Firefox though.
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?
> 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?
Yep. Thanks for this. Painted a great pic in my mind about the issue/process here.
Great, glad to help.
I understand what you are saying, but it doesn't make sense. It sounds like a really bad way to do software development.
It's fundamentally about decoupling. As the author of libfoo, I cannot keep up with all of the different Linux distros and how they do their thing. So you decouple the process by having two layers of maintainer; the upstream maintainer and the package maintainer. And I can't then also test my package with every other package on every other distro.
It has problems like anything else does, but it's pretty effective overall.
What specifically do you find bad about it?
It has problems like anything else does, but it's pretty effective overall.
What specifically do you find bad about it?
What's the alternative? If you will try installing random stuff you'll get dependencies hell. Another extreme is self contained software, when each application bundles its own dependencies. Android does that more or less. But such approach causes major bloat and also increases security risks because you need to patch each application and its dependencies (which are duplicated in the multiple variants) once vulnerabilities are discovered.
Any better ideas than these two?
Any better ideas than these two?
The bloat from self-contained software really isn't that much. It doesn't cause a space problem even on the small amount of space on an Android device.
It depends on how many dependencies we are talking about. And more than bloat, security issues are critical.
Package Managers. In Debian the package manager (and repositories) is the app store.
This is, to me, a point against package managers. Little Windows universe secret: Installers aren't that bad.
After using apt-get for everything, going back to manually finding an (untrusted) executable, running it, hitting a bunch of next buttons -- seems insane.
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.
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.
After simply using installers in Windows, dealing with conflicting package and library dependencies seems insane. I've been unable to use multiple applications on linux because of this issue whereas that would never happen on Windows where installers just have what they need without getting in each other's business.
So, I had to clean some viruses off a Windows 7 machine for a friend recently. I had to grab about six different bits of anti-malware software to do so. Some of that software came from famous vendors' sites where the downloaded software wasn't even protected by https. No real way to externally validate the item I was about to install on a system which is already known to be compromised.
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.
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.
Are you sure Microsoft's antivirus wasn't enough?
The (main) virus came through a user brainfart clicking on something she shouldn't have, so it got to install directly with admin privs. Amongst other things, it managed to block the MS AV from running properly and hijacked the DNS, which I had to manually reset. I can't recall how MS AV was blocked, sorry. Once it was all cleaned up I left it with MS AV active, though.
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.
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.
> installers just have what they need
Have you ever tried writing a Windows installer?
Have you ever tried writing a Windows installer?
What exactly is your point? Applications bundling their dependencies is the norm on all mass-market desktop and mobile platforms. So commercial developers of packaged software are used to it. Such developers even tend to bundle dependencies when targeting Linux, if they want to be distro-agnostic. In this respect, developers of open-source software are spoiled, because they can delegate dependency handling to the distro or, in many cases, the user.
Yes, several. Have you?
Untrusted by whom? It's the same vendor whether it comes from their site or the package repository.
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.
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.
It's the same vendor whether it comes from their site or the package repository.
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.
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.
Prove the repository maintainer doesn't blanket approve things because they are overwhelmed.
That's what the mailing list / debbugs are for. Each package has a maintainer(s) who are responsible for looking after the package creation and upload.
A new upload creates an audit trail that could be checked if needed.
A new upload creates an audit trail that could be checked if needed.
[deleted]
>Installers aren't that bad
Nothing stops you from getting Firefox on Debian the "Windows" way.
Nothing stops you from getting Firefox on Debian the "Windows" way.
Tried it, couldn't get it to work. This was Raspbian, though.
As far as I can tell, Mozilla doesn't provide official Firefox builds for any ARM Linux device.
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
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
Did you try to download the x86 build? If so, it's your fault. If they don't provide an arm build, or if you got the arm build, it's Mozilla's fault, not Debian's.
My contact details are in my profile - I'm happy to help you get this working if you're still interested. It can be hard to find correct instructions for things like manual installs, especially when distros like Raspbian can be slightly different from their upstream sources.
1. Unpack.
2. Run.
2. Run.
There's no such thing as downloading a random installer from a random website, and then running it with administrative priviledges!
The point of a distribution is to provide a complete, working system. It's not just a collection of independent components, it's curated such that the whole is coherent.
So the shit MS got blasted for: bundling IE with Windows.
Not even remotely comparable. Firefox is not a product of Debian, and Debian is not nor ever has been in a "monopoly" position with respect to any market.
I think you know as well as everyone else that that's not the same thing. MS did not provide an option to uninstall IE, where debian literally has dozens of FF alternatives at your fingertips.
MS didn't get blasted for the how, they got blasted for the why.
2 things: you have to manually install a Web browser. Under Debian, it is equally as easy to install Firefox as it is to install chromium and other competing browsers (no lock-in), and the big one: you are not compelled to pay for Debian like you are for Windows.
Doesn't matter, Debian hasn't a monopoly.
> Why does the operating system have any say on what applications get released and how often?
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.
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.
Debian isn't an operating system. Linux an operating system and is a small part of the Debian distribution.
> Debian isn't an operating system. Linux an operating system and is a small part of the Debian distribution.
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).
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).
You don't need to use the package manager. Users who want to use it will use it.
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.