1x64: Windows Subsystem for Podcasts

Show Feedback
#1

Jono Bacon, Jeremy Garcia, Bryan Lunduke, and Stuart Langridge bring you Bad Voltage, in which there is a great deal of disagreement about Microsoft's motives and Canonical's motives and our motives, and some of us mock other podcasters because we hate the community, and also:

  • 00:02:01 [Microsoft and Canonical release the "Windows Subsystem for Linux"](http://blog.dustinkirkland.com/2016/03/ubuntu-on-windows.html) at MS's Build developer conference to provide the Ubuntu command line on Windows. What's that all about, then? Bash in cmd.exe? This sounds like a good idea, right? What does it mean?
  • 00:32:17 Jono reviews the [iRig Pro](http://www.ikmultimedia.com/products/irigpro/) "all-in-one audio/MIDI interface for Apple products that fits in your pocket"
  • The OpenShot project have just released the latest version of their video editor in [AppImage](http://appimage.org/) format; a single downloadable file which runs on every Linux OS and doesn't need to be unpacked or installed. With tools like this and Gnome's xdg-app in the wings, whither the old Linux model of "distributions" and packaging every app half a dozen times? Can this discussion get beyond complaints about static linking or the difficulty of releasing Linux software?

Also, Bryan is speaking at [LinuxFest Northwest](https://www.linuxfestnorthwest.org/2016) in Bellingham, USA on April 23rd/24th 2016, and Stuart is at [Fosstalk](http://www.fosstalk.com/) in London, UK on August 6th with other Linux podcasters, if you want to buy them drinks or expensive laptops or something!

Download the show now!

#2
#3

@sil the main tool for how the emulate Marshall/Boogie sounds is a process called Convolution. Being an iterative process, it is computationally very hard. Conceptually it is actually pretty simple:

  • Put 1 sample into the amplifier of your choice.
  • Record what comes out
  • Make a diff between in and out.
  • Apply that diff to everything you want to process.

As for using the iRig in Linux, it is most likely just a standard USB audio interface - the value is in the software they bundle. This could be replaced with Guitarix or Rakarrack(? spelling) plumbed using JACK.

2 Likes
#4

I think @bryanlunduke missed the number one thing about this bash Windows thing.

SSH makes this worth it by itself. Putty sucks. Just being able to SSH into a droplet or something makes it all worth while.

Tim

1 Like
#5

If the argument for this entire thing is that “Windows needed a better SSH client”… I’m on board with that. But, in that case, why not make the announcement “Microsoft and Canonical collaborate on an SSH client that doesn’t suck for Windows”?

That, at least, makes some sense. Not a lot of sense, mind you. But more than anything I’ve heard so far.

#6

Any thoughts as to what this new venture for Microsoft and Canonical should be named?

Canonicow?

1 Like
#7

Any excuse: https://m.youtube.com/watch?v=Vhh_GeBPOhs

This is all the reasons for bash on Windows…

1 Like
#8

Alright, been listening since the first show, but had to register just to comment on this episode.

Having worked for a corporate client, whom mandated that only Windows machines issued and controlled by them are allowed to access their systems and codebase, running Linux in VM was a major pain in the ass. Shared directories just don’t seem to work that well on a Windows host. There were inconsistencies in refresh times, issues with permissions and occasional stalling (used both VirtualBox and VMWare Workstation, latter of which seemed to be generally less painful to use).

That’s just files. Networking was a much bigger problem. In order to get to some of the servers, we had to use an arcane VPN client that only had Windows binaries and somehow magically authenticated itself with a certificate that was bound to the corporate user account on that machine. The thing is, that VPN client managed to confuse the VM host by forcefully renaming its network interfaces, if any were in use when it was started - a reported bug, that was never fixed. And having, naturally, spotty wifi in their buildings, along with loosely fitting RJ45 jacks on their ethernet cables (some of which looking like a previous developer chewed on them in agony), losing the connection made the VPN client reconnect, happily snuffing out any connectivity to the running VM.

I’m fairly certain that had I worked as a Windows admin, I could have probably figured workarounds for all those issues. However, that’s not my profession nor platform of choice. When talk comes to dealing with Windows domain controllers, embedding things in SharePoint servers or other such mental abuse, I just want to crawl under my desk and weep until it all goes away. So, yeah, can’t say I subscribe to Bryan’s notion of VMs being always easier for developers to use.

3 Likes
#9

The music on the Ubuntu Podcast has more of a 1920’s sound. I’m with @bryanlunduke here in saying that the 40’s were great. The height of the swing era with the big bands were great. Dean Martin was starting his career. A man wouldn’t be caught dead in public without a suit, tie and hat on. Women were always dressed nice. Even I remember when ‘casual’, for a man, meant slacks, shirt, tie and a sports coat. But, hey, at least these days, one can go to a funeral in pajamas. :smirk:

1 Like
#10

I think Microsoft wants to run Docker containers on Windows in the end.

1 Like
#11

With regard to the packaging debate, it’s the single reason that I’ve used Arch on my main machine for the past few years. Yes, there is very little first party support from upstream but getting everything comfortably with yaourt from either the official repos and the other half of the time getting stuff from the AUR. However, I can see an argument for a more intelligent way of sorting out older required versions of libraries (the amount of -compat libraries that I have is nigh-on ridiculous).

1 Like
#12

What is wrong with Putty or Cygwin?

1 Like
#13

Did you ever try/were allowed to use Cygwin? Legitimately, I am curious.

#14

Thanks for discussing AppImage. Every time this topic comes up there is a heated discussion. I have been working in this field for around a decade now (starting with the klik project and now AppImage) and it seems like the idea of upstream packaging is increasingly getting traction on the Linux desktop platform now for apps like Arduino, Atom, Brackets, Chromium, Firefox, LibreOffice, and the likes. All of which I provide AppImages for at https://bintray.com/probono/AppImages. You can see how these get built at https://github.com/probonopd/AppImages

AppImage also enables application developers to do “upstream packaging” and provide AppImages to end users directly from the application authors without any intermediaries in between. So I think upstream-generated AppImages is where it really gets interesting: Projects like Krita, MuseScore, Pitivi, Scribus, StopGo, and Subsurface now provide AppImages of releases, and even more exciting, nightly or even continuous builds, directly from their websites.

As for updating, we are working on AppImageUpdate, a system that lets you just the binary delta between an older version and the latest version of an AppImage. Makes it extremely quick to update from one nightly snapshot to another; again with no intermediary between the user and the application author/packager. Works at the core but is still a bit rough around the edges, so a great place to contribute :slight_smile:

By the way, AppImages at the core are really just ISO files that are mounted at runtime. They contain everything the app needs to run that is not part of the base system (=Linux distribution). Should Gtk be bundled inside every AppImage? Well, the rule-of-thumb is that everything that cannot be expected to be part of the base system should be bundled. So it depends on which base systems you are targeting. As of today I would assume a not-to-recent version of Gtk to be part of the base system while the same cannot be expected for Qt currently.

3 Likes
#15

The problem is exactly how to define what can be assumed to be part of the system and what not. Think, for example, on Debian: the default install will give you a GNOME desktop, but there are alternative, also supported, ways that install different configurations. OK, perhaps Debian in all of its DE-based configurations always includes GTK+ and Qt because of default programs that require them, but what about Arch? A default Arch install doesn’t even install X11… How do you know whether GTK+ is available or not? What about KaOS, a distro that deliberately avoids GTK+?

I like XDG-APP and similar approaches better (Android apps!). If you provide a runtime for self-contained images, then you can forget about what’s on the system except for the runtime being present. The runtime would choose whether to use GTK+ or Qt or whatever is installed on the system, and the self-contained program would just call the API exposed by the runtime. Graphical toolkits seem to be the most graphical examples (pun intended), but other components may also fall into this kind of problem: I can think of keyrings, sound backends (gstreamer vs. Phonon), network managers or even fonts. This way you can reduce the amount of library code you must include into the image, work with a common runtime (helping development), increase security, etc.

Of course, I would limit self-contained images for those programs that nobody depends on. If the program provides an API or is extensively used as in pipes, etc., I prefer it to be packaged by the distribution mainly to have just only one copy that must be patched in case of a critical vulnerability or bug being found in it that affects all other programs that depend on it.

EDIT: Great episode!

2 Likes
#16

Looks like people are already working on making graphical apps work on the windows subsystem for Linux: https://www.slightfuture.com/how-to/x-on-wsl No dbus is the major issue thus far, it suggests.

#17

Agreed entirely. Also, @bryanlunduke claimed that this is all closed source – the windows bits are, but it’s running unmodified Ubuntu binaries, all of which are, of course, open. So that sounds a bit disingenuous, Bryan, old pal. It would of course be nice if the windows kernel parts that implement this were open, but I’d like it if the rest of the windows kernel were open too and that ain’t happening either.

1 Like
#18

Nice episode!

I liked the test because it was talking a bit about music. I don’t play the guitar (I try to play the piano and it’s hard enough :)) but I’m interested in music on Linux.

I also noticed OpenShot being released as an AppImage a few weeks ago so I went and learnt more about AppImage and it looks like a promising stuff for desktop apps. I was always impressed at softwares like Blender that can be just downloaded as a zip file, unzipped anywhere in the user’s home directory and launched directly. I recently had to learn more about Debian packaging process for work-related stuff and yep, it’s very complicated to stick to, so in the end we just maintain a PPA for Ubuntu users (our user base is very small, I have to say, and they all use Ubuntu). But that means old versions of our software live somewhere in the Debian repositories and that leads to problems sometimes. I’m curious to see what’s going to happen with snap packages (for Ubuntu), but in the meantime I really like the idea of AppImages!

#19

@sil in this podacst while @jonobacon was reviewing amplifier alternatives you implied that acoustic guitars are OK. I mainly play folk music so most of my instruments are acoustic but I have just been admonished for playing the Eric Clapton song “Layla” on my Gibson Les Paul because I have a Fender Stratocaster sat next to it on a stage stand. It appears my daughter is happy to let me use the wrong guitar if I don’t own the correct model but not otherwise. I can thus understand why @jonobacon is looking for for particular amplifier sounds. My Marshall amp sounds noticeably different to my Laney amp.

#20

I actually used windows eww but launching windows explorer I would even want pcmanfm. Actually getting gvfs backends working on linux and then using ssh as everything for file transfers could make everything. This could make desktop linux users that do tech support easier. If I was forced to use windows many linux file manager I wouild prefer. Also microsoft is a member with the openssh foundation and this will let more people aware of openssh-sftp server.

Please respect our code of conduct which is simple: don't be a dick.