Language Selection

English French German Italian Portuguese Spanish

Debian Just Died

Filed under
Linux

Sam Hocevar was elected the new DPL: Debian Project Leader Election 2007 Results.

It's useless to ask "how many voted for Sam", because the Debian elections are using an advanced Condorcet voting system with Schwartz Sequential Dropping, to guarantee that the winner is the candidate that is the less hated, if I am allowed to put it this way.

More Here.

re: Debian Just Died

Seems unlikely. They've existed for years with poor leadership, petty infighting, and lack of direction - why would a new figurehead change things so radically that the distro would die?

It's unlikely that businesses will change their opinion on Debian, in most cases, no corporate sponsorship for that distro keep most businesses away (i.e. they were a unfocused unfunded unmanaged distro before, and they still are - so where's the big change?).

As to Shuttleworth worrying - after pouring in truckloads of his own money, I would guess there's been plenty of "what if" discussions on that very topic (i.e. Debian's demise). It's doubtful that Ubuntu's "plan B" would be "well that's it folks, lets fold up shop".

I'm with stupid, round two

Also interestingly ranted by Beranger: How Do You Want Your Devices To Be Called Today?

Have you tried Etch?

I know there are a lot of users of other distros here, but have any of you tried Etch? It's quite good. It's highly configurable with lots of choices. I don't recommend it for the newbie, but the more experienced user can make what he wants of it. The lack of non-free multimedia items is an easy workaround if that's what you need.

And regarding the title "Debian Just Died", as Patrick Swayze said in movie Road House, "Opinions differ". I hope that the Debian developers keep up all that infighting and bickering and wandering around direction-less, because whatever they are doing sure produces a great distro.

re: Etch

Darkman wrote:
as Patrick Swayze said in movie Road House, "Opinions differ"

Wow, I'm not sure I know of anyone in real life that would admit to watching a Swayze movie, let alone be able to quote from it!

As to Etch, yeah, it's a pretty good distro. Apt, Network Install, total control over the install and config, what's not to like (oh yeah, that little picky thing called dependencies and poor repository control). For personal use, no worries, but when you attempt to bring something into a business, where the infrastructure can impact the bottom line, flakiness of the core development team and it's perceived lack of leadership or management does become a concern.

re: tried Etch?

Darkman wrote:

I know there are a lot of users of other distros here, but have any of you tried Etch? It's quite good. It's highly configurable with lots of choices. I don't recommend it for the newbie, but the more experienced user can make what he wants of it. The lack of non-free multimedia items is an easy workaround if that's what you need.

I've been using it on this website's server for several weeks to a month now. I've been fairly pleased overall. I'm quite pleased with what seems to be better performance and memory handling, but on the other hand I'm a bit bummed out by the three kernel opps I've had. But I've been running etch from a March 5 or so snapshot. I'm gonna dist-update including the newest kernel shortly. I hope I won't have any further problems.

As far as configurability, I don't find it as flexible as say slackware. Debian has its own way of doing some things, which was one of the motivating factors in leaving Gentoo. Gentoo was real bad about having its own weird way of doing things which made customizing or using prior knowledge more difficult. It's not as bad in Debian, but it's still there. So, sometimes I'm forced to look for the "debian" documentation as opposed to generic Linux or individual application docs.

UPDATE: Make that 4 kernel opps!

You say tomato I say tumahtoe

srlinuxx wrote:
UPDATE: Make that 4 kernel opps!

I think your opps went oops! (thank gfranken for turning me into a spelling nazi).

You should give CentOS a try, we have great luck with them running 24/7/365 with nary a hiccup.

re: You say tomato I say tumahtoe

lolol. yep, I guess so. Blushing

Well, I'm gonna do a dist-upgrade and see if that helps. There is a new bigmem kernel in stable now. But I might try CentOS if this keeps oops'in on me. Big Grin

Disclaimer

My penchant for mostly correct spelling and grammar (no one is perfect) does not an any way mean that I am a spelling nazi--it merely indicates that I enjoy correcting vonskippy Smile

It's Debian testing for me

I've used Debian testing since the end of January, which, now that Etch is done, should be getting a whole lot of packages coming in from unstable. It should be interesting. (Before that, I used Kanotix, a slightly modified version of Debian unstable, which I couldn't have done without help from Kanotix's support forums. Unstable does break from time to time.)

If you've ever run into "dependency hell" with an rpm-based distro, you'll find Debian's package management system to be a breath of fresh air, and there's a huge pool of software to choose from. You rarely run into problems if you stay within the pool. Debian does sometimes have its own way of configuring things, though.

The one thing Debian is deficient in is "newbie support," if you will. One seems to be expected to read the man pages and figure things out on one's own. (But for beginners, there's always Ubuntu.)

Debian Just Died

Like many readers I am not that up to date on the infighting of Debian's politics, but to say that Sam will be the end of Debian is absurd (how many said that about Mandrake/Mandriva when Gael left). I thought Beranger was above this kind of thing Sad

I was introduced to Debian through Ubuntu and now I have Debian Etch (while still in testing) running E17 and I have no problems with it. Granted it does not have the bling bling of other distro's and it takes about 2-3 years for a release, but I don't mind. If I want bleeding edge then I can always install Sidux or if I want to be one of the in-crowd I can go back to Ubuntu.

Isn't that the beauty of Linux, choice!

Ah well, I suppose Beranger is entitled to his opinion, but this does smack me of either petty jealousy or sour grapes.

re: debian comments

EmyrB wrote:
or if I want to be one of the in-crowd I can go back to Ubuntu.

Ha ha ha ha ha ha ha ha ha ha ha ha ha....

Oh, you weren't kidding - never mind.

Debian Just Died

> but this does smack me of either petty jealousy or sour grapes.

Can you define jealousy under the circumstances, please? Jealous ON WHAT?! I didn't run for the DPL Smile

Sour grapes?! In which way?! I can install Debian whenever I want. But I just don't want anymore.

Debian Died not because it will not run anymore. They might never release another stable, yet testing will be usable. Debian died as a distro you can trust. How could anyone trust Debian as an enterprise-grade distro, when the developers have elected as DPL a guy that creates kindergarten-like mutiny? C'mon.

re: debian

Béranger wrote:
>How could anyone trust Debian as an enterprise-grade distro

I think that's been a problem for them long before this recent leadership choice.

I know of several IT Shops that moved off of Debian after the IceWeasel nonsense showed that Debian, like their logo, is spiraling out of control.

What're you talking about?

Why, exactly, are you so upset about the choice of Sam Hocevar as the DPL?

Vous aimez faire grand bruit, non?

(And what the hell does Debian's changing the names/logos of Mozilla products to Iceweasel, Icedove, and Iceape have to do with its suitability as a server?)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

NVIDIA GeForce vs. AMD Radeon Vulkan Neural Network Performance With NCNN

With having added Tencent's NCNN tests to the Phoronix Test Suite with Vulkan acceleration, here is a look at the real-world impact by using RealSR-NCNN for scaling up with RealSR. Various NVIDIA GeForce and AMD Radeon graphics cards were tested for this initial NCNN / RealSR-NCNN Vulkan comparison. This is our first time looking at how well Vulkan performs in this area with the current state of the Linux drivers. The GeForce hardware was tested with the latest 450 series proprietary driver while on the Radeon side it was with Linux 5.9 and Mesa 20.3-devel using the RADV Vulkan driver. One of the Tencent developers working on NCNN has commented as well that using RADV's ACO offers a big boost for the performance, which fortunately is the current default for the RADV Vulkan driver. Read more Also: Phoronix Test Suite / OpenBenchmarking.org Now Has 600 Different Tests/Benchmarks

Kernel Space: Trenchboot, RAID10, Spelling Mistakes and Initcalls

  • Trenchboot Secure Launch Support For Linux Sees New Patches

    For a while now Oracle engineers and others have been working on Trenchboot as a means of secure launch/boot support when paired with the likes of Intel TXT and AMD SKINIT for trusted execution and configuring each piece of the software boot chain for trusted/secure handling. The latest kernel patches have been sent out for review for secure launching of the kernel. Earlier this year Oracle engineers sent out Linux kernel patches for Trenchboot while on Thursday the newest work surfaced.

  • Linux 5.10 To See RAID10 DISCARD Improvement - From 259 Seconds To Less Than 1 Second

    Queued today into the block subsystem's "-next" area ahead of the Linux 5.10 cycle kicking off next month are some MD RAID enhancements. In particular, thanks to Red Hat's Xiao Ni is improved RAID10 discard request handling. The change with a set of five SSDs in a RAID10 array on a test system dropped the mkfs.xfs time for creating an XFS file-system taking 4 minutes 39 seconds to less than 1 second... Quite a noticeable difference in that scenario.

  • Colin King: Kernel janitor work: fixing spelling mistakes in kernel messages

    The Linux 5.9-rc6 kernel source contains over 300,000 literal strings used in kernel messages of various sorts (errors, warnings, etc) and it is no surprise that typos and spelling mistakes slip into these messages from time to time. To catch spelling mistakes I run a daily automated job that fetches the tip from linux-next and runs a fast spelling checker tool that finds all spelling mistakes and then diff's these against the results from the previous day. The diff is emailed to me and I put my kernel janitor hat on, fix these up and send these to the upstream developers and maintainers. The spelling checker tool is a fast-and-dirty C parser that finds literal strings and also variable names and checks these against a US English dictionary containing over 100,000 words. As fun weekend side project I hand optimized the checker to be able to parse and spell check several millions lines of kernel C code per second.

  • Initcalls, part 2: Digging into implementation

    In the first part of this blog post series on Linux kernel initcalls, we looked at their purpose, their usage, and ways to debug them (using initcall_debug or FTrace). In this second part, we'll go deeper into the implementation of initcalls, with a look at the colorful __device_initcall() macro, the rootfs initcall, and how modules can be executed.

Graphics: AMD, KWinFT and Zink

  • AMD Sends Out Linux Kernel Support For Van Gogh APUs - Confirms DDR5 Memory, VCN3

    s a nice Friday afternoon patch series there is the 275k lines of code for wiring up the next-generation AMD Van Gogh APU support under Linux. Earlier this week there were the Mesa patches for AMD Dimgrey Cavefish and Van Gogh while today the kernel-side portion for Van Gogh was sent out for the AMDGPU kernel driver.

  • AMD Van Gogh APUs Spotted In Linux Patch, Features DDR5, Navi 2 iGPU

    AMD submitted the 45 Linux kernel patches, which weigh in at 275,000 lines of code, to enable Linux support for the coming APUs. The patches also reveal that Van Gogh comes with Video Core Next 3.0, which supports AV1 decode. In the past, Phoronix has found patches indicating VCN 3.0 (video encode) is native to the Navi 2 graphics engine. Pairing the Navi 2 / RDNA 2 graphics engine with DDR5/LPDDR5 could unlock quite a bit of graphical horsepower, as integrated graphics engines tend to respond well to increased memory throughput. Van Gogh is also predicted to come with Zen 2 cores, and it will certainly be interesting to see what kind of impact the improved memory throughput has on the Zen 2 architecture.

  • Roman Gilg: Universal means to specific ends

    Today new beta versions for all KWinFT projects – that are KWinFT, Wrapland, Disman and KDisplay – were released. With that we are on target for the full release which is aligned with Plasma 5.20 on October 13. Big changes will unquestionable come to Disman, a previously stifled library for display management, which now learns to stand on its own feet providing universal means for the configuration of displays with different windowing systems and Wayland compositors. But also for the compositor KWinFT a very specific yet important feature got implemented and a multitude of stability fixes and code refactors were accomplished. In the following we will do a deep dive into reasons and results of this recent efforts.

  • Mike Blumenkrantz: Engage Thrusters

    Briefly, zink copies the framebuffer state, there’s a number of conditions under which a new pipeline object is needed, which all result in ctx->gfx_pipeline_state.hash = 0;. Other than this, there’s sample count check for sample changes so that the shader can be modified if necessary, and then there’s the setup for creating the Vulkan framebuffer object as well as the renderpass object in get_framebuffer(). Eagle-eyed readers will immediately spot the problem here, which is, aside from the fact that there’s not actually any reason to be setting up the framebuffer or renderpass here, how zink is also flushing the current batch if a renderpass is active. The change I made here was to remove everything related to Vulkan from here, and move it to zink_begin_render_pass(), which is the function that the driver uses to begin a renderpass for a given batch.

Mozilla: Firefox for Android Nightly and Surveillance ('Telemetry')

  • More Recommended extensions added to Firefox for Android Nightly

    As we mentioned recently, we’re adding Recommended extensions to Firefox for Android Nightly as a broader set of APIs become available to accommodate more add-on functionality. We just updated the collection with some new Recommended extensions, including… Mobile favorites Video Background Play Fix (keeps videos playing in the background even when you switch tabs) and Google Search Fixer (mimics the Google search experience on Chrome) are now in the fold. Privacy related extensions FoxyProxy (proxy management tool with advanced URL pattern matching) and Bitwarden (password manager) join popular ad blockers Ghostery and AdGuard. Dig deeper into web content with Image Search Options (customizable reverse image search tool) and Web Archives (view archived web pages from an array of search engines). And if you end up wasting too much time exploring images and cached pages you can get your productivity back on track with Tomato Clock (timed work intervals) and LeechBlock NG (block time-wasting websites).

  • Jeff Klukas: The Nitty-Gritty of Moving Data with Apache Beam

    In this session, you won’t learn about joins or windows or timers or any other advanced features of Beam. Instead, we will focus on the real-world complexity that comes from simply moving data from one system to another safely. How do we model data as it passes from one transform to another? How do we handle errors? How do we test the system? How do we organize the code to make the pipeline configurable for different source and destination systems? We will explore how each of these questions are addressed in Mozilla’s open source codebase for ingesting telemetry data from Firefox clients. By the end of the session, you’ll be equipped to explore the codebase and documentation on your own to see how these concepts are composed together.

  • This Week in Glean: glean-core to Wasm experiment

    On the Glean team we make an effort to move as much of the logic as possible to glean-core, so that we don’t have too much code duplication on the language bindings and guarantee standardized behaviour throughout all platforms. Since that is the case, it was counterintuitive for me, that when we set out to build a version of Glean for the web, we wouldn’t rely on the same glean-core as all our other language bindings. The hypothesis was: let’s make JavaScript just another language binding, by making our Rust core compile to a target that runs on the browser. Rust is notorious for making an effort to have a great Rust to Wasm experience, and the Rust and Webassembly working group has built awesome tools that make boilerplate for such projects much leaner.

  • Data Publishing @ Mozilla

    Mozilla’s history is steeped in openness and transparency – it’s simply core to what we do and how we see ourselves in the world. We are always looking for ways to bring our mission to life in ways that help create a healthy internet and support the Mozilla Manifesto. One of our commitments says “We are committed to an internet that elevates critical thinking, reasoned argument, shared knowledge, and verifiable facts”. To this end, we have spent a good amount of time considering how we can publicly share our Mozilla telemetry data sets – it is one of the most simple and effective ways we can enable collaboration and share knowledge. But, only if it can be done safely and in a privacy protecting, principled way. We believe we’ve designed a way to do this and we are excited to outline our approach here. Making data public not only allows us to be transparent about our data practices, but directly demonstrates how our work contributes to our mission. Having a publicly available methodology for vetting and sharing our data demonstrates our values as a company. It will also enable other research opportunities with trusted scientists, analysts, journalists, and policymakers in a way that furthers our efforts to shape an internet that benefits everyone.