You are here

Agreguesi i feed

Clive Johnston: Bye bye LastPass, hello bitwarden

Planet Ubuntu - Dje, 03/12/2017 - 5:42md

I have been a loyal customer for a password manager called LastPass for a number of years now.  It all started when I decided to treat myself to an early Christmas present by purchasing the “Premium” version back in 2013, in order to take advantage of the extra features such as the mobile app.

Now, don’t get me wrong, I do think $12 is very good value for money and I was very happy with LastPass, but I must say this article really, really got my back up.  (Apparently I’m an “entitled user”).  Not only that but the fact that not one, but three of the Google ads on the page are for LastPass (now there’s a spooky coincidence!)

I do agree with a lot of other users that to double the price for absolutely no benefits is an extremely bitter pill to swallow, especially as there are a number of issues I been having regarding the security of the mobile app.  But anyways, I calmed down and the topic went out of my head until I received an email reminding me that they would automatically charge my credit card with the new $24 price.  Then, about a week later, as I watched a YouTube video by TuxDigital, he mentioned another password manager called bitwarden

So a big thank you to Michael for bringing this to my attention. Not only does it have way more features than LastPass, but it is also open source (code on GitHub), self host-able and the “Premium” version is only $10. My issues with the LastPass mobile app are gone in bitwarden and replaced with the option to lock the app with your fingerprint or a pin code, which is a nice happy medium of having to log out of LastPass and then re-enter your entire master code to regain access!

Also another feature I *beeping* love (excuse my French), is the app and vault allows you to store a “Google Authenticator” key in the vault and then automatically generates a One Time Password (OTP) on the fly and copies it to the device clipboard.  This allows it to be easily copied in when auto-filling the username and password, great for those who use this feature on their blogs.

4.15-rc2: mainline

Kernel Linux - Dje, 03/12/2017 - 5:02md
Version:4.15-rc2 (mainline) Released:2017-12-03 Source:linux-4.15-rc2.tar.gz Patch:full (incremental)

On the demise of Linux Journal

Planet Debian - Dje, 03/12/2017 - 3:54pd

Lwn, Slashdot, and many others have marked the recent announcement of Linux Journal's demise. I'll take this opportunity to share some of my thoughts, and to thank the publication and its many contributors for their work over the years.

I think it's probably hard for younger people to imagine what the Linux world was like 20 years ago. Today, it's really not an exaggeration to say that the Internet as we know it wouldn't exist at all without Linux. Almost every major Internet company you can think of runs almost completely on Linux. Amazon, Google, Facebook, Twitter, etc, etc. All Linux. In 1997, though, the idea of running a production workload on Linux was pretty far out there.

I was in college in the late 90's, and worked for a time at a small Cambridge, Massachusetts software company. The company wrote a pretty fancy (and expensive!) GUI builder targeting big expensive commercial UNIX platforms like Solaris, HP/UX, SGI IRIX, and others. At one point a customer inquired about the availability of our software on Linux, and I, as an enthusiastic young student, got really excited about the idea. The company really had no plans to support Linux, though. I'll never forget the look of disbelief on a company exec's face as he asked "$3000 on a Linux system?"

Throughout this period, on my lunch breaks from work, I'd swing by the now defunct Quantum Books. One of the monthly treats was a new issue of Linux Journal on the periodicals shelf. In these issues, I learned that more forward thinking companies actually were using Linux to do real work. An article entitled "Linux Sinks the Titanic" described how Hollywood deployed hundreds(!) of Linux systems running custom software to generate the special effects for the 1997 movie Titanic. Other articles documented how Linux was making inroads at NASA and in the broader scientific community. Even the ads were interesting, as they showed increasing commercial interest in Linux, both on the hardware (HyperMicro, VA Research, Linux Hardware Solutions, etc) and software (CDE, Xi Graphics) fronts.

The software world is very different now than it was in 1997. The media world is different, too. Not only is Linux well established, it's pretty much the dominant OS on the planet. When Linux Journal reported in the late 90's that Linux was being used for some new project, that was news. When they documented how to set up a Linux system to control some new piece of hardware or run some network service, you could bet that they filled a gap that nobody else was working on. Today, it's no longer news that a successful company is using Linux in production. Nor is it surprising that you can run Linux on a small embedded system; in fact it's quite likely that the system shipped with Linux pre-installed. On the media side, it used to be valuable to have everything bundled in a glossy, professionally produced archive published on a regular basis. Today, at least in the Linux/free software sphere, that's less important. Individual publication is easy on the Internet today, and search engines are very good at ensuring that the best content is the most discoverable content. The whole Internet is basically one giant continuously published magazine.

It's been a long time since I paid attention to Linux Journal, so from a practical point of view I can't honestly say that I'll miss it. I appreciate the role it played in my growth, but there are so many options for young people today entering the Linux/free software communities that it appears that the role is no longer needed. Still, the termination of this magazine is a permanent thing, and I can't help but worry that there's somebody out there who might thrive in the free software community if only they had the right door open before them.

Noah Meyerhans http://noah.meyerhans.us/ Category: debian | Noah Meyerhans

There’s cloud, and it can even be YOURS on YOUR computer

Planet Debian - Sht, 02/12/2017 - 11:09md

Each time I see the FSFE picture, just like on Daniel’s last post to planet.d.o, where it says:

“There is NO CLOUD, just other people’s computers”

it makes me so frustrated. There’s such a thing as private cloud, setup on your own set of servers. I’ve been working on delivering OpenStack to Debian for the last 6 years and a half, motivated exactly to fix this issue: I refuse that the only cloud people could use would be a closed source solution like GCE, AWS or Azure. The FSFE (and the FSF) completely dismissing this work is more than annoying: it is counter productive. Not only the FSFE shouldn’t pull anyone away from the cloud, but it should push for the public to choose cloud providers using free software like OpenStack.

The openstack.org market place lists 23 public cloud providers using OpenStack, so there is now no excuse to use any other type of cloud: for sure, there’s one where you need it. If you use a free software solution like OpenStack, then the question if you’re running on your own hardware, on some rented hardware (on which you deployed OpenStack yourself), or on someone else’s OpenStack deployment is just a practical one, on which you can always back-up quickly. That’s one of the very reason why one should deploy on the cloud: so that it’s possible to redeploy quickly on another cloud provider, or even on your own private cloud. This gives you more freedom than you ever had, because it makes you not dependent anymore on the hosting company you’ve selected: switching provider is just the mater of launching a script. The reality is that neither the FSFE or RMS understand all of this. Please don’t dive into the FSFE very wrong message.

Goirand Thomas http://thomas.goirand.fr/blog Zigo's blog

BlogSpam.net repository cleanup, and email-changes.

Planet Debian - Sht, 02/12/2017 - 11:00md

I've shuffled around all the repositories which are associated with the blogspam service, such that they're all in the same place and refer to each other correctly:

Otherwise I've done a bit of tidying up on virtual machines, and I'm just about to drop the use of qpsmtpd for handling my email. I've used the (perl-based) qpsmtpd project for many years, and documented how my system works in a "book":

I'll be switching to pure exim4-based setup later today, and we'll see what that does. So far today I've received over five thousand spam emails:

steve@ssh /spam/today $ find . -type f | wc -l 5731

Looking more closely though over half of these rejections are "dictionary attacks", so they're not SPAM I'd see if I dropped the qpsmtpd-layer. Here's a sample log entry (for a mail that was both rejected at SMTP-time by qpsmtpd and archived to disc in case of error):

{"from":"<clzzgiadqb@ics.uci.edu>", "helo":"adrian-monk-v3.ics.uci.edu", "reason":"Mail for juha not accepted at steve.fi", "filename":"1512284907.P26574M119173Q0.ssh.steve.org.uk.steve.fi", "subject":"Viagra Professional. Beyond compare. Buy at our shop.", "ip":"2a00:6d40:60:814e::1", "message-id":"<p65NxDXNOo1b.cdD3s73osVDDQ@ics.uci.edu>", "recipient":"juha@steve.fi", "host":"Unknown"}

I suspect that with procmail piping to crm114, and a beefed up spam-checking configuration for exim4 I'll not see a significant difference and I'll have removed something non-standard. For what it is worth over 75% of the remaining junk which was rejected at SMTP-time has been rejected via DNS-blacklists. So again exim4 will take care of that for me.

If it turns out that I'm getting inundated with junk-mail I'll revert this, but I suspect that it'll all be fine.

Steve Kemp https://blog.steve.fi/ Steve Kemp's Blog

My Debian Activities in November 2017

Planet Debian - Sht, 02/12/2017 - 5:55md

FTP master

As you might have read elsewhere, I am no longer an FTP assistant. I am very delighted about my new delegation as FTP master.

So this month I almost doubled the number of accepted packages to 385 packages and rejected 60 uploads. The overall number of packages that got accepted this month was 448.

Debian LTS

This was my forty first month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian.

This month my all in all workload has been 13h. During that time I did LTS uploads of:

  • [DLA 1188-1] libxml2 security update one CVE
  • [DLA 1191-1] python-werkzeug security update one CVE
  • [DLA 1192-1] libofx security update two CVEs
  • [DLA 1195-1] curl security update one CVE
  • [DLA 1194-1] libxml2 security update two CVEs

I also took care of an rsync issue and continued to work on wireshark.

Other stuff

During November I uploaded new upstream versions of …

I also did uploads of …

  • openoverlayrouter to change the source package Section: and fix some problems in Ubuntu
  • duktape to not only provide a shared library but also a pkg-config file
  • astronomical-almanac to make Helmut happy and fix a FTCBFS where he also provided the patch

Last month I wrote about apcupsd as the DOPOM of October. Unfortunately in November was the next power outage due to some malfunction in a transformer station. I never would have guessed that such a malfunction can do so much harm within the power grid. Anyway, the power was back after 31 minutes and my batteries would have lasted 34 minutes before turning off all computer. At least my spec was correct :-).

The DOPOM for this month has been dateutils.

As it is again this time of the year, I would also like to draw some attention to the Debian Med Advent Calendar. Like the past years, the Debian Med team starts a bug squashing event from the December 1st to 24th. Every bug that is closed will be registered in the calendar. So instead of taking something from the calendar, this special one will be filled and at Christmas hopefully every Debian Med related bug is closed. Don’t hestitate, start to squash :-).

Last but not least I sponsored the upload of evqueue-core.

alteholz http://blog.alteholz.eu blog.alteholz.eu » planetdebian

dbus, rsyslogd, systemd: Which one is the culprit?

Planet Debian - Sht, 02/12/2017 - 4:03md
I have been facing this issue since a few weeks on testing. For many weeks, it prevented upgrading dbus to the latest version that trickled to Testing. Having manually force-installed dbus via the Recovery Mode's shell, I then ran into this issue:


This is a nasty one, since it also prevents performing a clean poweroff. That systemd-journald line about getting a timeout while attempting to connect to the Watchdog keeps on showing ad infinitum.

What am I missing? Martin-Éric noreply@blogger.com Funkyware: ITCetera

Simos Xenitellis: How to set the timezone in LXD containers

Planet Ubuntu - Sht, 02/12/2017 - 1:06md

See https://blog.simos.info/trying-out-lxd-containers-on-our-ubuntu/ on how to set up and test LXD on Ubuntu (or another Linux distribution).

In this post we see how to set up the timezone in a newly created container.

The problem

The default timezone for a newly created container is Etc/UTC, which is what we used to call Greenwich Mean Time.

Let’s observe.

$ lxc launch ubuntu:16.04 mycontainer Creating mycontainer Starting mycontainer $ lxc exec mycontainer -- date Sat Dec 2 11:40:57 UTC 2017 $ lxc exec mycontainer -- cat /etc/timezone Etc/UTC

That is, the observed time in a container follows a timezone that is different from the vast majority our computer settings. When we connect with a shell inside the container, the time and date is not the same with that of our computer.

The time is recorded correctly inside the container, it is just the way it is presented, that is off by a few hours.

Depending on our use of the container, this might or might not be an issue to pursue.

The workaround

We can set the environment variable TZ (for timezone) of each container to our preferred timezone setting.

$ lxc exec mycontainer -- date Sat Dec 2 11:50:37 UTC 2017 $ lxc config set mycontainer environment.TZ Europe/London $ lxc exec mycontainer -- date Sat Dec 2 11:50:50 GMT 2017

That is, we use the lxc config set action to set, for mycontainer,  the environment variable TZ to the proper timezone (here, Europe/London). UTC time and Europe/London time happen to be the same during the winter.

How do we unset the container timezone and return back to Etc/UTC?

$ lxc config unset mycontainer environment.TZ

Here we used the lxc config unset action to unset the environment variable TZ.

The solution

LXD supports profiles and you can edit the default profile in order to get the timezone setting automatically applied to any containers that follow this profile. Let’s get a list of the profiles.

$ lxc profile list +---------+---------+ | NAME | USED BY | +---------+---------+ | default | 7 | +---------+---------+

Only one profile, called default. It is used by 7 containers already on this LXD installation.

We set the environment variable TZ in the profile with the following,

$ lxc exec mycontainer -- date Sat Dec 2 12:02:37 UTC 2017 $ lxc profile set default environment.TZ Europe/London $ lxc exec mycontainer -- date Sat Dec 2 12:02:43 GMT 2017

How do we unset the profile timezone and get back to Etc/UTC?

lxc profile unset default environment.TZ

Here we used the lxc profile unset action to unset the environment variable TZ.

 

Simos Xenitellishttps://blog.simos.info/

Daniel Pocock: Hacking with posters and stickers

Planet Ubuntu - Pre, 01/12/2017 - 9:27md

The FIXME.ch hackerspace in Lausanne, Switzerland has started this weekend's VR Hackathon with a somewhat low-tech 2D hack: using the FSFE's Public Money Public Code stickers in lieu of sticky tape to place the NO CLOUD poster behind the bar.

Get your free stickers and posters

FSFE can send you these posters and stickers too.

Hacking with posters and stickers

Planet Debian - Pre, 01/12/2017 - 9:27md

The FIXME.ch hackerspace in Lausanne, Switzerland has started this weekend's VR Hackathon with a somewhat low-tech 2D hack: using the FSFE's Public Money Public Code stickers in lieu of sticky tape to place the NO CLOUD poster behind the bar.

Get your free stickers and posters

FSFE can send you these posters and stickers too.

Daniel.Pocock https://danielpocock.com/tags/debian DanielPocock.com - debian

Debian LTS work, November 2017

Planet Debian - Pre, 01/12/2017 - 6:54md

I was assigned 13 hours of work by Freexian's Debian LTS initiative and carried over 4 hours from September. I worked all 17 hours.

I prepared and released two updates on the Linux 3.2 longterm stable branch (3.2.95, 3.2.96), but I didn't upload an update to Debian. However, I have rebased the Debian package on 3.2.96 and expect to make a new upload soon.

Ben Hutchings https://www.decadent.org.uk/ben/blog Better living through software

Mini-DebConf Cambridge 2017

Planet Debian - Pre, 01/12/2017 - 6:51md

Last week I attended Cambridge's annual mini-DebConf. It's slightly strange to visit a place one has lived in for a long time but which is no longer home. I joined Nattie in the 'video team house' which was rented for the whole week; I only went for four days.

I travelled down on Wednesday night, and spent a long time (rather longer than planned) on trains and in waiting rooms. I used this time to catch up on discussions about signing infrastructure for Secure Boot, explaining my concerns with the most recent proposal and proposing some changes that might alleviate those. Sorry to everyone who was waiting for that; I should have replied earlier.

On the Thursday and Friday I prepared for my talk, and had some conversations with Steve McIntyre and others about SB signing infrastructure. Nattie and Andy respectively organised group dinners at the Polish club on Thursday and a curry house on Friday, both of which I enjoyed.

The mini-DebConf proper took place on the Saturday and Sunday, and I presented my now annual talk on "What's new in the Linux kernel". As usual, the video team did a fine job of recording and publishing video of the talks.

Ben Hutchings https://www.decadent.org.uk/ben/blog Better living through software

I was trying to get selenium up and running.

Planet Debian - Pre, 01/12/2017 - 6:20md
I was trying to get selenium up and running. I wanted to try chrome headless and one that seemed to be usable seemed to be selenium but that didn't just work out of the box on Debian apt-get installed binary. hmm.

Junichi Uekawa http://www.netfort.gr.jp/~dancer/diary/201712.html.en Dancer's daily hackings

Debarshi Ray: Image wrangling with GEGL: an introduction

Planet GNOME - Hën, 20/11/2017 - 12:38md

One of the core dependencies of GNOME Photos, other than GTK+ and Tracker, is a library called GEGL. It is a GObject-based image processing library primarily developed for GIMP. GEGL is used by Photos to load pixels from files, create thumbnails, edit, share and export images.

Unfortunately, even though GEGL is a powerful and generic image processing framework, it can be hard to find documentation and code samples to refer to, and the pool of people who understand it well enough is relatively small. I am going to do a series of blog posts to address this by feeding the search engines. Hopefully this will be useful for new contributors to GIMP and GNOME Photos, and some of it can be folded back into the reference GEGL documentation; or maybe it will encourage adoption in new and interesting places.

Nodes and operations

Processing images with GEGL requires the creation of a graph, represented by a GeglNode. A GeglNode can either have a number of child nodes connected to each other forming a directed acyclic graph, or it can have a GeglOperation. An operation is where the actual image processing takes place. Multiple operations are chained together in a graph to obtain the desired outcome.

This is enough to get started with some basic effects and enhancements. Here is a snippet that takes a path to an input image, enhances the blacks and saves it as a PNG.

#include <gegl.h> … g_autoptr (GeglNode) graph = NULL; GeglNode *exposure; GeglNode *load; GeglNode *sink; graph = gegl_node_new (); load = gegl_node_new_child (graph, "operation", "gegl:load", "path", /* input path as C string */, NULL); exposure = gegl_node_new_child (graph, "operation", "gegl:exposure", "black-level", 0.03, NULL); sink = gegl_node_new_child (graph, "operation", "gegl:png-save", "bitdepth", 8, "path", /* output path as C string */, NULL); gegl_node_link_many (load, exposure, sink, NULL); gegl_node_process (sink);

Notice the many similarities with GStreamer.

There is a whole list of such filters to choose from. Such as gegl:cartoon to simulate a cartoon drawn with a black felt pen, gegl:mosaic to transform an image into a mosaic, gegl:saturation to change the colourfulness of the image, or gegl:posterize, which is used by the similarly named tool in GIMP.

Buffers

Image pixels are held in a GeglBuffer. Most applications would directly interact with a GeglBuffer at one point or the other. For example, to decode an image file and carry the pixels around instead of repeatedly decoding them off the storage. In the above code sample, the buffers were implicitly created by GEGL unbeknownst to us, but we can use a similar graph to load pixels off a file into a GeglBuffer.

#include <gegl.h> … g_autoptr (GeglBuffer) buffer = NULL; g_autoptr (GeglNode) graph = NULL; GeglNode *load; GeglNode *sink; graph = gegl_node_new (); load = gegl_node_new_child (graph, "operation", "gegl:load", "path", /* input path as C string */, NULL); sink = gegl_node_new_child (graph, "operation", "gegl:buffer-sink", "buffer", &buffer, NULL); gegl_node_link_many (load, sink, NULL); gegl_node_process (sink);

A loaded buffer can be then fed into a graph using a gegl:buffer-source.

As the custodian of pixels, GeglBuffer is similar to the role played by GdkPixbuf, but it has some extra features that are handy for image processing.

Most notably, a GeglBuffer is designed to handle massive images that are larger than the amount of physical RAM available on the system. Instead of holding all the pixels in a linear sequence of bytes, it splits them up into small tiles that can be paged out into a file when not in use. However, if necessary, it is possible to optionally dumb down a GeglBuffer by setting it up to use a single array of bytes, or forcing all tiles to be held in RAM.

A GeglBuffer is not restricted to a single pixel format such as RGB with 8 bits per channel. It can transparently handle a horde of formats — monochrome, Lab, HSL, etc. with different degrees of precision per channel. Finally, it is mipmap-capable.

All these features make GeglBuffer a very sophisticated data structure for storing image pixels. However, they aren’t that important for an introduction to GEGL, so we will save them for a future article.

Happy hacking

This is enough to start playing with GEGL. Here is the code used to create the above image, and is proof that knowing just this much is enough to do practically useful things.


Faqet

Subscribe to AlbLinux agreguesi