|
this is design by committee:
|
#
?
May 4, 2014 20:52
|
|
|
|
| # ? Jan 19, 2025 00:52 |
|
|
pseudorandom name posted:this is design by committee: i dont see anything wrong here
|
|
#
?
May 4, 2014 23:05
|
|
|
Bloody posted:i dont see anything wrong here its because you have jquery in your gang date
|
|
#
?
May 4, 2014 23:12
|
|
|
lol if you think i know anything about javascript
|
|
#
?
May 5, 2014 01:45
|
|
|
Bloody posted:lol if you think i know anything
|
|
#
?
May 5, 2014 01:45
|
|
|
Bloody posted:lol if you think
|
|
#
?
May 5, 2014 01:46
|
|
|
agreedo also agreed
|
|
#
?
May 5, 2014 01:50
|
|
|
Last Chance posted:its because you have jquery in your gang date also ill have you know that this gang tag was a gift 
|
|
#
?
May 5, 2014 01:54
|
|
|
gang date. the gently caress was i thinking
|
|
#
?
May 5, 2014 01:55
|
|
|
suspicious dish is too smart to be suckered easily, so i was driven to investigate docker its a shitshow but people are at least starting to talk about openstack integration and poo poo that could matter to non-startup-dipshits. moved from "utter bullshit" column to "pile of miserable techie wank" column in my head. also known as "poo poo to watch"
|
|
#
?
May 5, 2014 02:01
|
|
|
Keep in mind that I don't know that much about Docker's UI model, only the basics and how some of our customers are using Docker and how they want to use Docker and RHEL together. I know more about the underlying technologies of containerization, and there are plenty of great benefits there. For a simple example of how small you can make a container manager, see linux-user-chroot. Even that has a lot of fancy features. Linux is really the only platform where developers don't ship apps to users directly, they instead go through this middle-man called a "distribution" which only breaks your software and adds dumb politics on top. Docker, I think, has a real potential of providing an excellent server app distribution model where app developers ship their apps directly to users, which is a really good thing. Packages got us really far, but they're really outdated as a distribution technology in 2014, when we have so many better models in use today. Docker may not be the greatest thing in the world, but it's at least something more than what we have right now, and more people exploring the "app sandbox" and "app distribution" venues to invent and improve and make something better are always good.
|
|
#
?
May 5, 2014 02:17
|
|
|
Suspicious Dish posted:which only breaks your software and adds dumb politics on top on the other hand, debian
|
|
#
?
May 5, 2014 02:32
|
|
|
api call girl posted:on the other hand, debian That was the prime example I was thinking of, yes.
|
|
#
?
May 5, 2014 02:35
|
|
|
api call girl posted:on the other hand, debian even I won't endorse debian politics
|
|
#
?
May 5, 2014 02:48
|
|
|
But if Debian's politics died, I wouldn't have any use for this bulk order of popcorn I got at Costco the other day.
|
|
#
?
May 5, 2014 02:49
|
|
|
I just looked at ctte. There's an argument over having two menu systems, saying that two are bad and that we should only use one. One is Debian's dumb menu system which literally nothing uses, the other being a standard across literally every Linux DE and Linux app. The current train of thought is that they are going to define what the word "should" means in the context of Debian policy, because nobody can figure out what "should" means in a technical sense.
|
|
#
?
May 5, 2014 02:51
|
|
|
So, to take a step back, I think Ian is arguing that, by declaring the traditional menu system a "should," he's not introducing a problem into Policy that doesn't already exist, because our current use of "should" is all over the map. I agree with that statement as far as it goes, but I don't think it's a very useful observation. Because usage of "should" is currently all over the map, it doesn't provide any clear guidance to the packager, which is what the goal should be. When working on a section of Policy, I try to fix issues like that when we see them. There are various "should" requirements in Policy that I think are actually wishlist bugs, among them man pages and doc-base integration. I don't believe those should share a word with things I would file as important bugs. That's a long-standing bug in Policy that needs to get fixed. I think it's up to the TC to figure out what the requirements on maintainers are for the two separate menu systems in Debian at the moment, and to express those in some clear way so that the project knows what the requirements are and to what extent we are holding maintainers to them. I don't think it's up to the TC to decide how Policy handles normative language. So, I think the questions before the TC are: 1. Should programs that make sense in the context of a typical DE (I realize there's some fuzziness around this) all have desktop files? If so, what level of Policy requirement should that be? (Please be more specific than "should" -- maybe talk in terms of expected bug severities? For reference, I consider man pages and doc-base integration to be a wishlist bug.) 2. What level of Policy requirement is providing traditional menu files in individual packages, using the same terminology? Things that I don't think are TC issues: * Whether desktop files should be documented in Policy at all. There appears to be consensus that they should be, and I don't think anyone is disagreeing with that consensus, so there is no dispute there. * How Policy should formally represent the distinction between different levels of requirements. I respectfully suggest that this is a question of the maintenance and style of the Policy documentation, not a question of technical policy for the project, and is therefore a matter for the Policy Editors to decide, not the TC. What we're looking for from the TC is clear guidance on what the requirements are and what level of severity those requirements have. We clearly need to find some way to represent that in English once we have that guidance, but I don't think this is the place to decide how to do that or what the implications are for all the other "should" statements in Policy.
|
|
#
?
May 5, 2014 02:51
|
|
|
smdh if you cant figure out the meaning of "should" in the context of requirements
|
|
#
?
May 5, 2014 02:53
|
|
|
imagine an operating system controlled by a committee of fishmechs
|
|
#
?
May 5, 2014 02:55
|
|
|
somebody go demand that Debian conform to RFC 2119
|
|
#
?
May 5, 2014 02:59
|
|
|
pram posted:imagine an operating system controlled by a committee of fishmechs its windows
|
|
#
?
May 5, 2014 03:10
|
|
|
theadder posted:its windows hardly. windows isn't driven by wikipedia based technical "accuracy". it's 20 years of long tail cruft with a focus grouped coat of paint every three years
|
|
#
?
May 5, 2014 03:15
|
|
|
politics are the point of debian its a real democracy with hundreds of committees. democracy is ugly. the products are not.
|
|
#
?
May 5, 2014 03:19
|
|
|
interesting cuz debians a real piece of poo poo rhel ftw
|
|
#
?
May 5, 2014 03:20
|
|
|
Notorious b.s.d. posted:politics are the point of debian
|
|
#
?
May 5, 2014 03:39
|
|
|
Debian tech committee members "should" go jump off a bridge, tia
|
|
#
?
May 5, 2014 03:40
|
|
|
Suspicious Dish posted:Debian tech committee members "should" go jump off a bridge, tia i just try not to look at how the sausage is made
|
|
#
?
May 5, 2014 03:52
|
|
|
Let me just drop this tarball in my production server from some random vendor and fprot it with some fun roll loops --this thread
|
|
#
?
May 5, 2014 03:55
|
|
|
api call girl posted:Let me just drop this tarball in my production server from some random vendor and fprot it with some fun roll loops No, we don't run Debian
|
|
#
?
May 5, 2014 04:05
|
|
|
Suspicious Dish posted:So, I think the questions before the TC are: lol
|
|
#
?
May 5, 2014 04:13
|
|
|
https://lists.debian.org/debian-ctte/2014/04/ I'll just leave this here.
|
|
#
?
May 5, 2014 04:15
|
|
|
also debian is good despite the committee stuff i think it has a side benefit of giving an outlet to the fishmechs that insulates them from the real work the systemd stuff was pretty hilarious tho, was worried they were gonna make the wrong decision to support bsd debians or whatever other pet projects
|
|
#
?
May 5, 2014 04:17
|
|
|
Progressive JPEG posted:also debian is good
|
|
#
?
May 5, 2014 04:26
|
|
|
Reading a debian mailing list will make any reasonable person cry, roll his eyes or fall asleep. That's ok. That's just how decisions have to be hashed out, if you're going to do it democratically and in public. There is no benevolent dictator. Random dudes with commit perms cannot determine policy quietly behind the scenes People think about poo poo, talk about poo poo, fish mech the gently caress out of every little thing and hopefully reach consensus
|
|
#
?
May 5, 2014 04:30
|
|
|
Debian is slow, out-of-date, and gives an unreasonable amount of concern for weird edge cases like Debian/kFreeBSD, a project that only two people actually use, three of which work on it. Its packages in its repositories are maintained by volunteers that often have no idea what they're doing. They constantly invent new "standards" that are custom and bad like the "traditional menu" system. It attempts to build a great OS by allowing users to mix/match components to unreasonable amounts of flexibility. Debian still ships my software with patches that are broken. I still get bug reports upstream for crashes that those patches cause upstream, and I have personally asked the maintainers of the packages to remove their patches many times over. I do not like shipping broken software to users, and it's extremely exhausting to have to explain to users that it's out of my control. People think that because there's this magical third-party in here, that the software is of good quality, or that it's more secure or something. I have no idea why people think that some volunteer who doesn't know much about anything writing a custom build script to unpack a tarball and make a .deb is better than having the developer themselves writing a custom build script to unpack a tarball and make a .deb. It's controlled by a large constitution that's somehow more vague and has more interpretations than the US Code of Conduct. Most conflicts end in fishmechian "that's not how I read the policy, let's agree to disagree" statements. Things don't get done, they just get bikeshedded about over and over. And over. It took Debian close to a year to decide that yes, a modern init system is something we should have, and then took close to 5 months to pick the only sane option (that was documented, feature-rich, didn't have a contributor license agreement, didn't have any active maintenance, didn't have a bug list 8,000 lines long)
|
|
#
?
May 5, 2014 04:32
|
|
|
Notorious b.s.d. posted:Reading a debian mailing list will make any reasonable person cry, roll his eyes or fall asleep. That's ok. That's just how decisions have to be hashed out, if you're going to do it democratically and in public. Why do you think slow, tired consensus is the best way to build working software?
|
|
#
?
May 5, 2014 04:33
|
|
|
Suspicious Dish posted:Its packages in its repositories are maintained by volunteers that often have no idea what they're doing. 
|
|
#
?
May 5, 2014 04:34
|
|
|
Suspicious Dish posted:Why do you think slow, tired consensus is the best way to build working software? Debian is an institution that collates, documents, and distributes software. It's very, uh, institutional. By design. Actually writing the software is probably better done elsewhere
|
|
#
?
May 5, 2014 04:40
|
|
|
Notorious b.s.d. posted:Actually writing the software is probably better done elsewhere
|
|
#
?
May 5, 2014 04:45
|
|
|
|
| # ? Jan 19, 2025 00:52 |
|
|
and most people use it through one of many sub-distros thatve refined the mess a bit
|
|
#
?
May 5, 2014 05:48
|
|