1 |
On 24/11/14 19:13, Marc Stürmer wrote: |
2 |
> Am 24.11.2014 um 19:25 schrieb Gevisz: |
3 |
> |
4 |
>> I switched from Ubuntu 10.04 to Gentoo just because it forced closing |
5 |
>> window button "x" to the upper-left corner of the window in Unity of |
6 |
>> Ubuntu 12.04 while I used to look for it in the upper-right corner. :) |
7 |
>> |
8 |
>> So, I see no reason that those that hate systemd would not do the same. |
9 |
> |
10 |
> I also did for my own server. |
11 |
> |
12 |
> But the real strength and home of Debian on a server is in the |
13 |
> corporate environment, and in a CE you are facing other challenges, |
14 |
> namely: |
15 |
> |
16 |
> * long term support (meaning for a few years), |
17 |
|
18 |
I'd clarify this even more to say almost transparent to install upgrades |
19 |
within that release cycle |
20 |
|
21 |
> * stable releases with a more or less stable and predictable release |
22 |
> cycle, |
23 |
|
24 |
debatable - i would suggest "better tested" than stable otherwise there |
25 |
would be no need for debian bugzilla |
26 |
|
27 |
> * steady stream of security updates as long as the release is being |
28 |
> supported. |
29 |
> |
30 |
> Which also explains why in that field so many people are so heavily |
31 |
> against SystemD, because it is still: |
32 |
> |
33 |
> * quite a young software project, which needs more time to mature in |
34 |
> their eyes, |
35 |
> * still a fast moving target, with adding more features over features |
36 |
> with every new release, |
37 |
> * maybe also the philosophical aspect that it violates one of the |
38 |
> primary paradigms of UNIX: do one thing only and do that well, |
39 |
> * and it forces them to learn a new way to configure their system, if |
40 |
> they would use it. |
41 |
> |
42 |
|
43 |
+1 for all of these |
44 |
|
45 |
>> I disagree: the downloading all that crap also takes a lot of time. |
46 |
> |
47 |
> Downloading binaries takes of course some time, yes. But downloading |
48 |
> e.g. the source code of Chromium compared to the binary of Chromium |
49 |
> does take a multiply longer. And after the download of the binary you |
50 |
> just need to unpack it and are ready to run it, on Gentoo you need to |
51 |
> compile it. |
52 |
> |
53 |
|
54 |
I would argue the opposite. I would say that because of the portage |
55 |
binary features, and the "possibility an upgrade may not even compile" |
56 |
it forces me to do better QA on updates. as an example, I would be less |
57 |
likely to test and update in debian or red hat before applying a series |
58 |
of necessary updates. on gentoo cluster i would install off the cluster |
59 |
first, ensure everything went smooth then distribute the binaries. for |
60 |
issues with conf changes *cough ISC bind and freeradius cough* it means |
61 |
that i'm well prepared. it also means that continuous kernel |
62 |
configuration changes for the various udev updates can be masked and |
63 |
prepared for in a better way than "oh this week's updates require i |
64 |
reboot the server" |
65 |
|
66 |
good luck using custom kernel or initram with the major distros -- i |
67 |
found that that was a surefire method to bork things, non bootable and |
68 |
confused app-manager both at the same time. |
69 |
|
70 |
> So binaries are by every mean faster to download and run than |
71 |
> downloading the source, compiling it and then running it on a server. |
72 |
> Even downloading the biggest archives and installing (without |
73 |
> configuration) is normally done in under one minute. That's the time |
74 |
> saving aspect, and you got no broken ebuilds. Of course you got |
75 |
> another can of worms that may be bug you instead. |
76 |
> |
77 |
> And if you don't like the example of Chromium, then take MySQL e.g. |
78 |
> instead. |
79 |
> |
80 |
> People in a CE rarely have the time to deal with the added complicity |
81 |
> of Gentoo compared to binary based distributions, and therefore Gentoo |
82 |
> just don't fit for most of them. |
83 |
> |
84 |
+1 gentoo in a very real sense is "my distribution". my /etc and my |
85 |
/var/lib/portage/world and i have geezer-linux-desktop and |
86 |
geezer-linux-server |
87 |
but in a corporate environment it is someone else's problem be that low |
88 |
level... rather than have an inhouse developer to fix the web |
89 |
application bugs, they would have a "Next Generation Unified Threat |
90 |
Management Firewall" to block people taking advantage of those bugs. |
91 |
the question is how it is sold. |
92 |
also it is a lot easier for someone to click on the little balloon that |
93 |
says "updates pending" than to think about what it is they are doing. |
94 |
equally it is easier to convince a business to buy one server instead of |
95 |
trying to cluster two or more -- then you _must_ do updates at 3am, but |
96 |
updates are somehting that should happen when the updater is most alert |
97 |
imho. the business shifts the responsibility of the down time in the |
98 |
same way as they would shift the responsibility of the lower levels of |
99 |
distro management. |
100 |
|
101 |
> The thing is: compiling your own binaries on a production server is |
102 |
> something many people won't like, because it takes power from the |
103 |
> other processes away for that time. |
104 |
+1 |
105 |
> |
106 |
> And having a fully fledged C/C++ compiler running on your server is a |
107 |
> security hole, if you are paranoid enough. |
108 |
> |
109 |
+1 |
110 |
> Of course you could setup just a compiling server for all of your |
111 |
> other servers, but this takes time and adds complexity. |
112 |
> |
113 |
surprisingly little - honestly. |
114 |
>> Steady "release cycle" is also not so good. |
115 |
> |
116 |
> It depends on your case. |
117 |
> |
118 |
> All the major BSDs, FreeBSD, NetBSD and OpenBSD, have had a steady |
119 |
> release cycle - a new release every half year - for almost two decades |
120 |
> now and they are content with that. |
121 |
> |
122 |
OT: |
123 |
one day i thought to try a BSD but then as a penance for my sins i also |
124 |
read kuro5hin and there was a wonderfully scalding attack [1] on de |
125 |
raadt. the truth is probably no where near to the rant but it always |
126 |
think of it when i see attacks on lennart. but this did make me |
127 |
discover something that i thought i'd share here |
128 |
"BSD is a unix written by unix people for the pc |
129 |
Linux is a unix written by pc people for the pc" |
130 |
but its also interesting to note portage has a nod to BSD's "ports |
131 |
collection" |
132 |
|
133 |
|
134 |
WARNING link is not safe for work and may cause stomach ulcers |
135 |
[1] http://www.kuro5hin.org/story/2010/6/11/9571/98591 |