not all change is progress
July 11, 2016
Direct download links: MP3 & Ogg
01:03:06 SUSE Studio
Hitting it out of the park once again, the world’s best Linux podcast returns with the latest FOSS news, showcases an effective desktop and server sandboxing technology and talks self-build distro creation with SUSE Studio.00:01:24 News
End of an era: Linux distributions will soon stop supporting
Ubuntu encourage developers to make apps convergent
The Next Generation Operating System on a Key
That Eye-Fi card you could have bought a year ago is going to stop working on September 16th
Amazon Prime will knock $50 off an Android phone if you look at Amazon’s lock-screen ads
Cracking Android’s full-disk encryption is easy on millions of phones – with a little patience
Google’s My Activity reveals just how much it knows about you
Facebook wins privacy case against Belgian data protection authority
Two clicks for more privacy
Under Mayer deal, Mozilla could walk away and still get more than $1 billion if it doesn’t like Yahoo’s buyer
Context Graph: It’s time to bring context back to the web
The Web We Have to Save
Want to easily run existing applications in a secured environment? Firejail could be just what you’re looking for. To find out a little more, check out this article from Linux Magazine last year.
As ever, thanks to our Monthly Supporters whose stalwart efforts really do keep the show on the road. And, as Joe suggested, if you can’t help us out financially at the moment you could make a real difference by telling somebody else about the show.
Some comments from Josh Scott prompted Joe to reiterate how we decide what technologies to cover on the show.
Will offered some thoughts on changes in packaging, and also pulled Jesse up on his view of Arch, whilst Christopher Wininger did the same to Paddy (and his ongoing suspicion of modern dev practices).
Nathan D Smith pitched in with some thoughts about Samsung’s acquisition of Joyent, and what that might mean for the non-Windows/Linux datacentre. Thanks, Nathan.
01:03:06 SUSE Studio
SUSE Studio is a web-based tool that’s straightforward enough to let most anyone build their own SUSE-based custom distro. Prompted by a request to look at the Studio-built GeckoLinux, we decided to see how we’d get on ourselves.
“N-guy-en”? :) The closest English approximation to this common Vietnamese name is something like “win”.
Git doesn’t force you to push every commit you make to the public repo. The maintainer can make a separate branch with the commits squashed into one large change and fetch only those changes into the public repo when there is a new release. Some open-source projects even ask that pull requests be squashed into one commit in their contributing guidelines. In short, git doesn’t build that small wall for you, but it doesn’t stop you from building it yourself.
I think the criticisms Paddy gives are valid but they’re part of the current culture and wouldn’t be fixed just by switching to another VCS.
I agree. I think when Paddy said “git” he was really referring more to GitHub and similar services that encourage projects to host their VCS repos publicly. From the reference to Sourceforge, I infer that Paddy thinks there was value in the more restrained approach of only posting the source code for point releases and not the real time commit log between releases.
Agree with both points, just to add that we use git tags for stable releases, and active development is often done in feature branches.
Paddy, I’d be interested to know which projects
you’re talking about.
Since the barrier of entry for setting up an online repo is much lower these days ~ the quality varies a lot. If you’re not depending on this code why does it matter?
A little like the television industry talking down the low quality of YouTube, ignoring that nobody watches most of it.
Or was this statement more critical of the shift
in attitudes/practices of developers,
unrelated to their work being used or not?
Will — I have a (bad) habit of talking in shorthand. I was intending to convey both that Git as a tool isn’t necessarily the best thing out there for developers (it arguably is, for maintainers), and also — as you identified — that sites like GitHub have contributed to an ‘every change in the open’ approach. And it’s the latter that I feel is the real problem here, mainly for the reason I articulated: that it creates an expectation that has spread around the industry that low quality/bugs/constant change are not all just acceptable, but simply a part of life.
You are obviously confusing git with github. I’ll agree with you on github. github is a POS everybody should ignore and instead use their own hosting. However when you lump git and github together and say they are not for developers I just shake my head. Why do you troll your audience?
I highly recommend the talk “Release Management in Large Free Software Projects”, recorded here: https://www.youtube.com/watch?v=IKsQsxubuAA
ABSTRACT: Time based releases are made according to a specific time interval, instead of making a release when a particular functionality or set of features have been implemented. This talk argues that time based release management acts as an effective coordination mechanism in large volunteer projects and shows examples from seven projects that have moved to time based releases: Debian, GCC, GNOME, Linux, OpenOffice, Plone, and X.org.
(Some more interesting historical context for
that is Linux’s own change from big
multi-year “development branches” to the
quarterly release process: https://lwn.net/Articles/94386/
I’d like to hear more about the distinction between developers and maintainers. I guess a maintainer is someone overseeing a large project with many contributoers? And a developer someone who works primarily alone? What should developers be using instead of git?
A concern I have with making a hard
distinction here –
is that from what I’ve seen developers who join the project may become maintainers gradually, as part of learning the code-base, taking on responsibility as they become more experienced.
Giving developers one set of tools and
maintainers another – could just make it
harder to have developers grow into the
Also, tasks that DVCS is typically good, at are useful for developers too: bisecting history, performing complex merges and interactive rebase.
While it’s fair to be critical of git/github practies, using different tools for developers and maintainers seems like it mostly introduces extra stumbling blocks to overcome.
I agree with Ryan, it’s a cultural problem
not one of the tool.
More mature projects implement new features in branches of “master” or “develop” and also have branches of stable versions. SaltStack then uses tags to mark the releases which are packaged just as FreeBSD’s release engineers tag certain revisions as 10.3 or 11.0. You can have parts of this workflow with SVN or CVS but you can’t track local changes. There’s a clear benefit in having a public (or just remote) fork with a feature branch over having a bunch of patches on your laptop because you can’t just check them in on the One Repository to rule them^W all of the project.
BTW: branches in CVS and SVN never go away so you can’t/don’t want to just goof around there to get familiar with the part of the code you want to work on.
I must say, I really enjoy this podcast. Something about British humor… Just my 2 cents, I think Firefox is WAYYYY better than Chrome these days, I only use Chrome for Netflix and Google apps, Firefox seems to be much less of a memory hog than Chrome as of late. Also, Java. I don’t hate Chrome, I use Chrome, I just don’t think it is as good. Love your show!
I don’t know about the criticism of Mayer for the Mozilla deal — it seems kind of brilliant on her part. If Yahoo is sold, that’s pretty much the end for her, so why not make deals that are massively unfavorable for Yahoo if it is sold?
I didn’t tie the two parts of my comment about packaging and Arch together, but I meant them to go together. What I was getting at is that a lot of people think of Arch as being buggy/beta level, but really it just tracks upstream releases (like Jesse said maybe part of this reputation comes from issues with packages in the AUR as well). So when upstream introduces new bugs or totally changes how everything works (e.g. systemd), those disruptions get passed along into Arch (unless they are so bad that the Arch maintainers block the release). In a snaps-driven world, everyone would then be getting packages closely following the upstream releases. I wonder if that would have any impact on how stable and tested new releases are. Though I have to say that I have been using Arch for a year and a half now and haven’t had any major packaging related issues.
The secure-k folks don’t violate the GPL until they
sell/ship anything ;)
I wonder if it’s just a thumbdrive with hardware encryption (or just a “lock”?) and a branded Debian with some proprietary applications on top.
Oh, and there was a guy at FOSDEM or Chemnitzer Linuxtage
this year who took a closer look at such a WiFi sdcard.
It’s running a little busybox based Linux which he made
run an access point and a web server sharing all the
files on the card.
Imagine the fun if everybody’s camera would just share all their pics with any wifi-enabled device…
“removing vim because who uses that”. !@#$%^
Um… I use Vim all the time… Maybe I just don’t know any better, been using it for about 15 years… so…
Yeah, I use vim as my IDE of choice. All CLI to the shell is done in vim and then I press a key over the line I want executed. All compiling, interfacing with git, etc. goes through vim. So it makes very little difference which desktop flavor I use, though I use XFCE, because vim is what I live in. However one of the luddite pontificators said when he was making a distro using Suse Studio he removed vim from the distro because nobody uses that. I have a feeling he was just trying to get comments here and wasn’t really so !@#%^#@# stupid.
It was a joke but thanks for playing.
But yeah, “!@#$%^” would even be close to my reaction when someone would remove vim from my systems… also mess up my .vimrc and I would need cursing skills like Sidney from GrrlPower: http://grrlpowercomic.com/archives/197
Comments are now closed.
The content of this website, and that of the podcasts produced by the website owners, is licensed under the Creative Commons Attribution-NonCommercial 4.0 International License.