Övningar 1 till “Privat på nätet”

Den första delen av Privat på nätet handlar om hur vi hanterar lösenord. Fungerande lösenord är ett fundament is sig själv, och också för sådant som kryptering och nyckelhantering som kommer senare.

Skapa vettiga lösenord

Bra lösenord är inte ord, utan fraser/meningar. Använd http://www.passwordmeter.com för att konstruera  vettiga lösenord för det som är viktigt. Använd inte samma lösenord på mer än ett ställe. Det som inte är viktigt (dvs de flesta) kan ni lämna som de är. Skapa också ett nytt master password som  är mycket starkt och inte används till något annat.

Installera en lösenordshanterare

Det finns en uppsjö av lösenordshanterare, och om du redan använder en och är nöjd finns det ingen anledning att byta. Annars, gå till https://lastpass.com  och installera den. lastpass är gratis till datorn, vill du använda den till mobilen kostar det en slant.

När du installerar lastpass skall du använda ett starkt lösen som master password som du ju redan har skapat.

Installera ghostery

ghostery visar och kan också blockera de flesta av de trackers och cookies som används för att  rutinmässigt spåra oss på nätet.  Gå till  https://www.ghostery.com/try-us/download-browser-extension och installera tillägget. Som en del av installationen kommer en del frågor. Kryssa i så att allt blir blockerat och “alert bubble” visas. Besök sedan din favoritsajt som t ex di.se och se vad ghostery blockerar.

Vissa sajter funkar inte när ghostery gör sitt jobb. Bekanta dig med hur du kan tillfälligt stänga av den (tyvärr, det varierar beroende på vad ni använder, jag vet helt enkelt inte detaljerna på Windows och MacOS. Men svårt är det inte)

 

Det var allt för idag!

 

Advertisements

How many users does Fedora have?

I happened to start a long discussion thread on the Fedora devel mailing list. My first message was (abridged):

While we’re on it (in the form “how many devs do we have”): How hard/impossible/unsuitable would it be to get a usable estimate on the # of users, per package?

Here are so many problems, technical, policy, resources, (others?). That said, feedback in the form “How many users uses/installs my package” would IMHO be a great input for any packager. It would be the difference between dropping the package in a black hole vs getting a message back from the community.

Somewhere down this road, Ben Cotton remarked  that before we can resolve how this should be done we need to define the questions to ask. Here, an attempt to summarize this, some 50 messages later.

General

We will probably not be able get useful absolute numbers. However, relative numbers and trends should be both possible and useful.

Privacy concerns blocks collecting  of otherwise useful info. Based on this, I have more or less limited the questions to what can be deduced from installed software and yum/dnf logs.

Q: How much are products and spins are actually used?

Metthew has indicated that we need some usage counts  on our products in bz #1156007. Now, shouldn’t spins be treated the same way?

Q: How is the package I created actually used?

As a packager, it would be great to have some feedback if users actually installs “my”  package. Seemingly trivial, this is about motivating packagers. The most interesting question here is likely How many users have installed my package directly?  (i. e., not as a dependency). Here is also the negative feedback How many users have actively removed my package?

Here are a lot of alternatives see e. g. this message.  I suggest we limit this to what might add some motivation and feedback to a packager.

Q Which package does users prefer?

Info on the relative popularity of alternative implementations like postfix/sendmail/exim4 or KDE/Gnome would probably improve some discussions and decision making.

Q: Which non-Fedora packages does users need to install?

When users needs to install applications which not are in Fedora repos, this is an argument to package those. This falls into two categories: sw packaged in non-fedora repos like COPR and rpmfusion or unpackaged software. Trying to probe for specific unpackaged software e. g., chrome is technically possible but might raise privacy concerns.

Q: How are packages updated?

This question is partly about how the  overall  update process works., so we can improve it over time. But it’s also hint for a packager whether a certain feature/fix needs to be back-ported to older branches.

Q: How many users uses platform x/architecture Y?

Knowing usage of platforms (KVM, bare metal, AWS, etc.) and architectures (i386, x86_64, amd64, etc.) is important input when analysing the impact of not supporting any of these in some respect.

Questions not asked due to privacy concerns:

• Default browser
• Number of installed “real” users (i. e., # true multi-user installations).
• Default desktop
• How many monitors are attached?
• What daemons are running on the system?

Getting spotify into Fedora – part 2

Getting spotify into fedora hasn’t been easy. Not for technical reasons, but legal.  Clearing spotify’s legal conditions, Fedora’s legal concerns and also the packaging rules as defined by the FPC has taken more than half a year. Actually, the FPC process made part of my previous post obsolete.  But at last we see some light in the tunnel, with the packages going to rpmfusion instead of Fedora.

As of now (exactly right now!) the lpf-spotify-client package has been published for F-19 on rpmfusion. This package basically automates the process to download, build and install a rpm based on the Spotify debian package.. Enjoy

Also, this means that the lpf (Local Package Factory) framework becomes live. We have currently lpf-skype and lpf-flash-plugin under way.  I also have lpf-msttcore-fonts in my plans. When all this flies, there will actually be a way to handle a lot of the things in all those Fedora post-installation guides out there in a more organized manner.  Which might be a Good Thing.

Getting Spotify and Skype into Fedora.

Fedora is really about free software, which can be used, inspected and modified according to our needs. Still, there are  commercial, closed source applications which offers a great value without being free. They are typically only distributed as binary code.

So, let’s download the binary application, build an rpm and make it available to fedora users!  For some apps this works fine,  you most often find them on rpmfusion.

However, some applications are not only closed-source but also non-redistributable. This means that rpmfusion can’t host such a package. Instead, each user must download and install the software. Examples include skype and spotify.

One could of course package some kind of ‘skype-installer’ which makes this. However, this would mean several installers and commands to handle them which might become messy. So, instead I wrote some silly shellscripts which I called lpf, which should be read Local Package Factory. The basic idea with lpf is to provide a common framework for these applications.

Using lpf,, there is now a package lpf-spotify-client. After installing this, one just have to click on the lpf-spotify-client icon  or use ‘lpf update’ in the terminal. This will download spotify, build an rpm and install it.  It’s meant to be as simple as possible, but it will always need a user actually pushing the button.

One advantage is the packaging. The lpf-spotify-client actually contains and uses spotify-client.spec, an already tested spec. There’s nothing lpf-specific  in it. OTOH, the lpf-spotify-client.spec is just some boilerplate code which should be simple to use in other applications.

One problem I’ve seen so far is the process. When I submit lpf-spotify-client for review, what the reviewer checks is lpf-spotify-scient.spec. However, this is just boilerplate code and not much to check. The central spotify-client.spec gets no attention, although the quality of this spec is what the user really is affected by. Obviously, we need to fix the review process if there will be more of these.

Now, the lpf command can actually do much more. It supports the complete package life-cycle: install,  update, remove. The upstream is at https://github.com/leamas/lpf. Here is a more in-depth presentation of the package.

The lpf-spotify-client package is now in f20 updates-testing and  rawhide if you want to give it a try. lpf-skype needs a reviewer, but looks good to me. We’ll see if this idea for a framework handling non-distributable files is the way to go until those software vendors sees the light and at least make their clients re-distributable.

Fedora: writing the update message… three times.

OK, trying to make a blog which actually shows up in planet.fedora. We’ll see…

Tired of writing the same update message when doing the git upstream commit, when editing the specfile changelog and when submitting the bodhi update request? Some pieces which might help:

• If you are making an upstream git commit first, I have a script gitspec
  available at http://github.com/leamas/pkg-scripts. This can create a new specfile changelog and/or bump the release based on the upstream git commit.
• When you have the proper changelog, it would be real nice if fedpkg used the changelog as the default update messages. I have submitted patches for this, and a patched fedpkg is available at http://leamas.fedorapeople.org/fedpkg (which is a valid yum repo).
• Don’t forget fedpkg clog. Using this you will generate a file clog reflecting the spec changelog which you can inspect, edit and finally use as the git commit message with -F clog.

Streaming video on Linux – the state of the art…

OK, I need to watch at streaming video at my Linux desktop and HTPC boxes. This is one of those areas where Winblows and MacOS actually works, and Linux just don’t make it. Yet.
The usecase is simple: the Swedish site svtplay. It’s actually a fantastic site, lot’s of content, good content. And free content.. But this site is similar to lots of other sites out there.  The common denominator is commercial, high-quality content. Sometimes they are free public service sites like svtplay, but most are paid services.

Svtplay uses Flash. A lot of people keep complaining in their support forums about not supporting HTLM5. However. this decision is not theirs, it’s the copyright owners. And since there is no working DRM system for HTML5, they don’t accept it. Full stop. In fact, some of them don’t even like Flash and wants the services to use Silverlight instead, making things even worse for Linux clients. Netflix is one of those services which have been forced to use Silverlight instead of Flash.

The hardware I use is the typical HTPC stuff: An anemic Intel Atom  paired with an ION GPU. This works perfectly OK using offline, downloaded media with e. g., VLC works fine. But Flash does not work – the plugin is not using hardware acceleration. Actually, at one point Flash did support hardware acceleration (which worked fine for me, on Nvidia). But Adobe  pulled it back. The lack of hardware acceleration in the Flash plugin is the main problem which make Linux just don’t work for this kind of hardware.

So, what’s the alternatives?

• google chrome have a deal with Adobe to deliver an updated Flash plugin called Pepper flash, which might get hardware acceleration one day. See this bug
• The gnash project aim to deliver a fully open-source Flash plugin. They do support hardware acceleration, but is not compatible with the Flash version used in svtplay. Seem to be making slow progress.  See their website
• Mozilla has started the shumway project to display Flash SWF files native in the browser: Blog post. This will not work until Mozilla fixes the use of local codecs (i. e., gstreamer on Linux): post , bug And the shumway plugin needs a new plugin interface scheduled for Firefox 18. Besides all these obstacles, FF actually is able to display a supported video format such as WebM in a fullsreen video on my hardware.
• There’s a good articlle on gnash and shumway here.
• There are  Swedish attempts to fix a downloader for svtplay at huggpunkt.org, svtplay-dl and pirateplay.se . Of these, svtplay-dl looks most promising. It can be piped directly to a viewer like vlc or ffplay except for HLS streams, which must go to disk first.
• Related is that Silverlight seems to work under wine, with some patches: phoronix blog post
• Looking at the silverlight attempt, it strikes me that the flash plugin + Firefox under wine actually might have hardware acceleration. Initial tries fails, missing support for flash, but it shouldn’t be  a big deal given that silverlight works?!
• Virtual Box has (experimental) hardware accelerated windows guest drivers, so has also VMware player. Problem is that Atom isn’t really the CPU to run virtual guests on.

Although things are not that good as of today, there’s really a lot happening here. Seems that real soon, perhaps Q1-13, the silverlight+wine solution will mature and Firefox and/or chrome will be able to present H264 videos using hw accelerated drivers. And all this thanks to Android, WebOS, and Valve ‘s Linux client which have breath some life into the Linux desktop infrastructure.

2013 might be the year when I build my next Linux HTPC, this time on e. g., a Tegra: No watts, no fan, no noise, graphics driver in kernel used also by android and thus maintained.