The horror

While trying to set up my mail system, I ran into multiple tutorials to figure out what was the best way to avoid multiple error messages, mainly because you, like me (you silly human!), simply copy and pasted random stuff from stack overflow, and tutorials in howtoforge and places like that…

The mistakes

You tried something like this

or this:

The pain

so you ended up with something that looks similar to this:

Resignation

So what worked for me was to leave the service in the master.cf as I had it working…

and simply add to master.cf

and in the main.cf

The light

Sieve filtering started to work after these changes :)

• Check This article that gave me that life saving line

Como renovar visa como Venezolano con prorroga y no morir en el intento

Si llegaste hasta este lugar, es porque eres posiblemente Venezolano, y estas en la penosa necesidad de necesitar una prorroga, pero tambien debes renovar tu visa de residente sea en el pais que estes.

Ya que no encontre informacion clara de el proceso, aca dejo los pasos que tuve que seguir en Alemania:

1. Solicitar la prorroga en la pagina de Saime, y pagar el monto.
2. Mientras llega la prorroga, llama a la embajada de Venezuela que te corresponde y solicita una constancia de tramite de prorroga.
3. Comunicate con la autoridad de migracion de el pais donde necesites renovar tu visa, y solicita la extension de tu visa, asegurate de entregar la constancia de que estas tramitando tu prorroga.
4. En el transcurso del tiempo entre que solicitas la cita para extender tu visa, y el momento de la cita, puede ser que la prorroga te llegue, aparecete en la cita con tu flamante prorroga, si esta no llega, te otorgaran un permiso temporal, mientras te llega la prorroga, una vez que te llegue, dirigete al paso 3.
5. Disfrute de dos años mas de estancia :)

Cuanto tiempo toma?

Entropia. No estoy seguro de cuanto tiempo toma, hay personas a las que le toma un par de meses, y a otros les toma 3-6 meses… asi que a esperar.

No se como solicitar la prorroga!

Una explicacion flash: Una vez que ingreses con tu usuario y contraseña en la pagina de saime:

1. Situate en la opcion “En el extranjero” -
2. Mueve el mouse (Horizontalmente funciona bastante bien) hacia la opcion: “Obtencion de prorroga de pasaporte electronico”
3. Luego de ver un anuncio sobre la prorroa, deberias poder ver esto:
4. En caso de que los pasos arriba mencionados no funcionen, una vez que logres ingresar a la web de saime con tu usuario y contraseña, puedes intentar esta url directamente: https://tramites.saime.gob.ve/index.php?r=inicio/inicio/prorrogaconsular

Si tienes alguna duda, puedes escribirme a @foursixnine en instagram o en twitter, o en ‘i+blog @ foursixnine punto io’

Nachdem es inzwischen keine Version von openSUSE mehr gibt in welcher der Apache zu alt ist um HTTP/2 zu unterstützen, gibt es eigentlich keine Ausrede mehr um dieses nicht einzusetzen. Tatsächlich ist die Installation auf openSUSE auch schon hervorragend vorbereitet, man muss lediglich berücksichtigen, dass HTTP/2 nicht mit dem Multi-Processing-Module (MPM) Worker kompatibel ist, welches immer noch der Standard ist.

Um HTTP/2 zu aktivieren ist zunächst ein kompatibles MPM zu installieren. Eine gute Wahl ist hierbei das MPM Event, welches unter openSUSE durch das Paket apache2-event bereitgestellt wird.

sudo zypper install apache2-event

Alle notwendige Konfiguration kann anschließend in der Datei /etc/sysconfig/apache2 vorgenommen werden:

1. Das korrekte MPM auswählen: APACHE_MPM=event.
2. Das HTTP2-Module durch hinzufügen von http2 zum Wert von APACHE_MODULES aktivieren.
3. Den Wert HTTP2 zu APACHE_SERVER_FLAGS um die von openSUSE mitgelieferte Konfiguration für HTTP/2 zu aktivieren.

Ab dem nächsten, per systemctl restart apache2 durchführbaren, Neustart ist der Server dann per HTTP/2 zu erreichen.

Um für Browser per HTTP/2 nutzbar zu sein muss der Server übrigens TLS reden, da Firefox und Chrome HTTP/2 nur für sichere Verbindungen unterstützen. Das sollte heutzutage aber sowieso der Standard sein.

I have just added Sea Island support to flashrom. This puts the R600 style SPI interface behind a pair of indexed registers, but otherwise is highly compatible.

While only tested on the first Sea-Island type SPI interface (Bonaire), support should work for everything up to and including Polaris, for a grand total of 240 devices supported today.

Bonaire was the introduction of this relocated register interface. Sadly there was an issue with this chip. There are 256bytes of SPI data registers, but registers 0xd8 through 0xE8 shifted up 0x10. There's an ugly work-around for that, but it works fine and the bit of extra cpu overhead is not an issue with a slowish interface like SPI. This shift was fixed for the next ASIC though, and Hawaii no longer needs that workaround.

As for my ordered hw...
* I still need to get a Tahiti/Hainan or Oland. So there are a few dozen Southern Islands cards to be added still.
* The HD4650 i ordered turned out to be an HD2600. The seller mistook one club3d card for another with the same passive cooler. He did not bother to even compare the connectors :(
* I did get a passive X300 (rv370) and X1300 (rv515) for which i will start REing now, so that i can extend flashrom support to all PCIE devices.

As always, the code is available here.

Vor wenigen Tagen ist die Kraft Version 0.82 erschienen.

Es handelt sich um ein weiteres Bugfix-Release zu Kraft 0.80, es enthält aber zusätzlich einige Features, die von Benutzern angefragt wurden.

Es wurden folgende Probleme gelöst:

• „Dokument per Email versenden“ ist repariert.
• Falsche Verwendung von einer Lokalisierungsfunktion hat für falsche Übersetzungen und Fehlermeldungen auf der Konsole gesorgt. Das wurde beseitigt.
• Die Nachfrage, ob Änderungen am Katalog verworfen werden sollen, wurde repariert.
• Einige Fehler im Setup-Code von Kraft wurden beseitigt.
• Viele weitere, kleine Verbesserungen.

Folgende neue Features wurden implementiert:

• Zusätzlich zu Thunderbird kann Email nun über das Tool xdg-email versendet werden, um andere EMail-Clients wie KMail zu unterstützen. Um xdg-email zu verwenden, muss in der Kraft-Konfigurationsdatei im Abschnitt [system] folgender Wert gesetzt werden: mailUA=xdg.
• Der Kalkulations-Dialog für Vorlagen wurde überarbeitet. Elemente ohne Funktion wurden beseitigt und das Benutzer-Interface wurde verbessert.
• Zeit-Kalkulationen können in Vorlagen jetzt feiner geplant werden. Dazu ist in der Zeitkalkulation die Zeit-Einheit jetzt einstellbar und nicht mehr fix auf Minuten eingestellt.

Wir freuen uns über jede Anregung zu Kraft. Fehlermeldungen und Verbesserungsvorschläge werden über den Github Issue Tracker entgegengenommen.

Viele Erfolg mit Kraft!

Hallo,

I just had a little struggle getting the current tumbleweed to run on the original Raspberry Pi (first generation, though the revision with larger RAM).

Just in case this helps anybody: I did not have any luck with a fresh openSUSE Tumbleweed image of one of the current arm6 builds. Don’t know why.

Here’s what I did:
– Download a pretty old known-good OpenSUSE 13.1 built by Bernhard Wiedemann

http://www.zq1.de/bernhard/linux/opensuse/raspberrypi-opensuse-latest.img.xz

Unzip, dump it to SD Card

xz -d raspberrypi-opensuse-latest.img.xz
dd if=raspberrypi-opensuse-latest.img of=/dev/mmcblk0 bs=8M

Boot up, change to text console (CTRL + ALT + F2)
Log In (root/linux)

Change Password (passwd)

nano /etc/zypp/repos.d/oss131.repo
Change baseurl line to
baseurl=http:/download.opensuse.org/ports/armv6hl/tumbleweed/repo/oss/
Save and get out (CTRL+X, Y)

#Resize partition and FS as this build won’t do:
# Adjust to more if your card is larger or to less if you need a more advanced partitioning scheme

parted resize 3 16G

resize2fs /dev/mmcblk0p3

zypper ref

zypper up gzip rpm

zypper dup –download in-advance

#(super conservative, get all needed packages first) – This is going to take quite a while

reboot, power cycle

Note that you will end up with a system booting into X11 login. You should probably change the default systemd target and maybe also get rid of some software. And you really don’t want a server with ssh password “linux”, so better don’t skip changing the PW

 

I like Dolphin, the default KDE file manager, a lot. I have used it for over 9 years. There are many features that I use regularly that I wouldn’t want to live without. In this post, I like to share my personal top 5. Some features are more obvious, others are hidden features.

1) Split windows

The split window view can be opened with the F3 key or by clicking on the Split icon. This is great for copying files from one location to another. Just drag and drop the files from left to right (or vis versa).

2) Integrated terminal

The build-in terminal can be opened by pressing the F4 key or by clicking on Control –> Panels –> Terminal. This is handy for the few Linux applications that need to be downloaded from an external website. For example: Oneplay Codec pack and Codeweavers Crossover Linux. The terminal automatically opens in the location that your are visiting, allowing you to directly input the zypper cli commands.

3) Show hidden files

Sometimes you want to edit or remove a configuration file. These files are often located in hidden folders in your Home directory. By showing the hidden files, you are able to navigate to these locations with ease.

4) Open With

The ability to open a file with the application of your choice is very handy. I like to open images with Gwenview by default. But for editing, I like to open them with Kolourpaint or GIMP. This feature allows me to do this with minimal effort.

5) Previews

You would think that this feature would be nr. 1. But unfortunately Preview didn’t always work as advertised. This was mainly a problem during the Qt 4 days (2009 – 2014). The Preview function is working without issues since the Qt 5 version of Dolphin. You can enable previews by clicking on the associated button. You can use the slider in the bottom right, to increase or decrease the size of the previews.

Published on: 21 October 2018

A new release of Kraft, the Qt- and KDE based software to help to organize business docs in small companies, has arrived.

A couple of days ago version 0.82 was released. It mainly is a bugfix release, but it also comes with a few new features. Users were asking for some new functions that they needed to switch to Kraft with their business communication, and I am always trying to make that a priority.

The most visible feature is a light rework of the calculation dialog that allows users to do price calculations for templates. It was cleared up, superflous elements were finally removed and the remaining ones now work as expected. The distinction between manual price and calculated price should be even more clear now. Time calculations can now not only done in the granularity of minutes, as this was to coarse for certain usecases. The unit for a time slice can now be either seconds, minutes or hours.

[caption id=“attachment_936” width=“516”] New calculation dialog in 0.82[/caption]

Apart from that, for example sending documents per email was fixed, and in addition to doing it through thunderbird, Kraft can now also utilize the xdg-email tool to work with the desktop standard mail client, such as KMail.

Quite a few more bugfixes make this a nice release. Check the full Changelog! Update is recommended.

Thanks for your comments or suggestions about Kraft!

FOSSCOMM (Free and Open Source Software Communities Meeting) is the pan-Hellenic conference of free and open source software communities. It is addressed at programmers, students and anyone else interested in the open source movement, despite their background. This year hosted by our friends at Heraklion, Crete.

Personally, I've been to many conferences during the year and I wanted to present the projects I'm rooting for.

I applied for 3 talks, all on Saturday.

My first talk was about GNOME. It's a talk from FOSSCOMM 2013 but with new information and of course main reason was to promote GUADEC 2019. The file of the talk are on Github.

My friend Kyriakos interviewed me about GNOME. Here you can find the video:


My second talk was about Nextcloud. Usually I make a general talk about Nextcloud and then Panteleimon Sarantos follows with Nextcloud Pi. This year, I preferred to use Frank's keynote at Nextcloud conference. I would like to thank him providing me his files. I made some minor changes. You can find the file on Github.

My friend Kyriakos interviewed me about Nextcloud. Here you can find the video:


Finally, a very cool project that I'm fired up lately is GNU Health. So my third and final talk had to do with it. The reason that I'm fired up is because openSUSE sponsors the project, and also because it's closer to my profession. I would like to thank Dr Luis Falcon and Axel Braun. I met them at openSUSE conference 2018 and I liked the project. I wanted to get involved so I started promotion and translation. So I asked them for their presentation files and I made a mix of them. The file I used are on Github.

This conference isn't only about presenting but it's also socializing. I met my FOSS friends. I talk to them over the internet and I surely meet them once a year.

I had a booth with promo materials from all 3 projects and some I got from my trips to other conferences abroad. Since I was there to promote GUADEC, I invited as many people as I could as volunteers and I also invited as many sponsors as I could find.

Here are some pictures...

FOSSCOMM Day 1 at the booth

FOSSCOMM minutes before my GNOME presentation.

GNUHealth presentation

FOSSCOMM Day 2 at the booth

FOSSCOMM booth, promo materials


When they will upload our talks, I will add them here.

I would like to thank GNOME Foundation for sponsoring my trip to Heraklion.

Remember that time when ATI employees tried to re-market their atomBIOS bytecode as scripts?

You probably don't, it was a decade ago.

It was in the middle of the RadeonHD versus -ati shitstorm. One was the original, written in actual C poking display registers directly, and depending on ATIs atomBIOS as little as practical. The other was the fork, implementing everything the fglrx way, and they stopped at nothing to smear the real code (including vandalizing the radeonhd repo, _after_ radeonhd had died). It was AMD teamed with SUSE versus ATI teamed with redhat. From a software and community point of view, it was real open source code and the goal of technical excellence, versus spite and grandstanding. From an AMD versus ATI point of view, it was trying to gain control over and clean up a broken company, and limiting the damage to server sales, versus fighting the new "corporate" overlord and people fighting to keep their old (ostensibly wrong) ways of working.

The RadeonHD project started april 2007, when we started working on a proposal for an open source driver. AMD management loved it, and supported innovations such as fully free docs (the first time since 3dfx went bust in 1999), and we started coding in July 2007. This is also when we were introduced to John Bridgman. At SUSE, we were told that John Bridgman was there to provide us with the information we needed, and to make sure that the required information would go through legal and be documented in public register documents. As an ATI employee, he had previously been tasked by AMD to provide working documentation infrastructure inside ATI (or bring one into existence?). From the very start, John Bridgman was underhandedly working on slowly killing the RadeonHD project. First by endlessly stalling and telling a different lie every week about why he did not manage to get us information this time round either. Later, when the RadeonHD driver did make it out to the public, by playing a very clear double game, specifically by supporting a competing driver project (which did things the ATI way) and publicly deriding or understating the role of the AMD backed SUSE project.

In November 2007, John Bridgman hired Alex Deucher, a supposed open source developer and x.org community member. While the level of support Bridgman had from his own ATI management is unclear to me, to AMD management he claimed that Alex was only there to help out the AMD sponsored project (again, the one with real code, and public docs), and that Alex was only working on the competing driver in his spare time (yeah right!). Let's just say that John slowly "softened" his claim there over time, as this is how one cooks a frog, and Mr Bridgman is an expert on cooking frogs.

One particularly curious instance occurred in January 2008, when John and Alex started to "communicate" differently about atomBIOS, specifically by consistently referring to it as a set of "scripts". You can see one shameful display here on alex his (now defunct) blog. He did this as part of a half-arsed series of write-ups trying to educate everyone about graphics drivers... Starting of course with... those "scripts" called atomBIOS...

I of course responded with a blog entry myself. Here is a quote from it: "At no point do AtomBIOS functions come close to fitting the definition of script, at least not as we get them. It might start life as "scripts", but what we get is the bytecode, stuck into the ROM of our graphics cards or our mainboard." (libv, 2008-01-28)

At the same time, Alex and John were busy renaming the C code for r100-r4xx to "legacy", inferring both that these old graphics cards were too old to support, and that actual C code is the legacy way of doing things. "The warping of these two words make it impossible to deny: it is something wrong, that somehow has to be made to appear right." (libv, 2008-01-29) Rewriting an obvious truth... Amazing behaviour from someone who was supposed to be part of the open source community.

At no point did ATI provide us with any tools to alter these so-called scripts. They provided only the interpreter for the bytecode, the bare minimum of what it took for the rest of the world to actually use atomBIOS. There never was atomBIOS language documentation. There was no tooling for converting to and from the bytecode. There never was tooling to alter or create PCI BIOS images from said atomBIOS scripts. And no open source tool to flash said BIOSes to the hardware was available. There was an obscure atiflash utility doing the rounds on the internet, and that tool still exits today, but it is not even clear who the author is. It has to be ATI, but it is all very clandestine, i think it is safe to assume that some individuals at some card makers sometimes break their NDAs and release this.

The only tool for looking at atomBIOS is Matthias Hopfs excellent atomdis. He wrote this in the first few weeks of the RadeonHD project. This became a central tool for RadeonHD development, as this gave us the insight into how things fit together. Yes, we did have register documentation, but Mr. Bridgman had given us twice 500 pages of "this bit does that" (the same ones made public a few months later), in the hope that we would not see the forest through the trees. Atomdis, register docs, and the (then) most experienced display driver developer on the planet (by quite a margin) made the RadeonHD a viable driver in record time, and it gave ATI no way back from an open source driver. When we showed Mr. Bridgman the output of atomdis in september 2007, he was amazed just how readable its output was compared to ATI internal tools. So much for scripts eh?

I have to confess though that i convinced Matthias to hold off making atomdis public, as i knew that people like Dave Airlie would use it against us otherwise (as they ended up doing with everything else, they just did not get to use atomdis for this purpose as well). In Q2 2009. after the RadeonHD project was well and truly dead, Matthias brought up the topic again, and i wholeheartedly agreed to throw it out. ATI and the forkers had succeeded anyway, and this way we would give others a tool to potentially help them move on from atomBIOS. Sadly, not much has happened with this code since.

One major advantage of full openness is the ability to support future use cases that were unforeseeable at the time of hardware, code or documentation release. One such use-case is the today rather common (still) use of GPUs for cryptocurrency "mining". This was not a thing back in 2007-2009 when we were doing RadeonHD. It was not a thing when AMD created a GPGPU department out of a mix of ATI and new employees (this is the department that has been pushing out 3D ISA information ever since). It was also not considered when ATI stopped the flow of (non shader ISA) documentation back in Q1 2009 (coinciding with radeonHD dying). We only just got to the point of providing a 3d driver then, and never got near considering pushing for open firmware for Radeon GPUs. Fully open power management and fully open 3d engine firmware could mean that both could be optimised to provide a measurable boost to a very specific use-case, which cryptocurrency mining usually is. By retreating in its proprietary shell with the death of the RadeonHD driver, and by working on the blob based fig-leaf driver to keep the public from hating the fglrx driver as much, ATI has denied us the ability to gain those few 10ths of percents or even whole percents that there are likely to be gained from optimised support.

Today though, miners are mostly just altering the gpu and memory frequencies and voltages in their atomBIOS based data tables (not touching the function tables). They tend to use a binary only gui tool to edit those values. Miners also extensively use the rather horrible atiflash. That all seems very limited compared to what could have been if AMD had not lost the internal battle.

So much for history, as giving ATI the two fingered salute is actually more of an added bonus for me. I primarily wanted to play around with some newer ideas for tracing registers, and i wanted to see how much more effective working with capstone would make me. Since SPI chips are simple hardware, and SPI engines are just as trivial, ati spi engines seemed like an easy target. The fact that there is one version of atiflash (that made it out) that runs under linux, made this an obvious and fun project. So i spent the last month, on and off, instrumenting this binary, flexing my REing muscle.

The information i gleaned is now stuck into flashrom, a tool to which i have been contributing since 2007, from right before i joined SUSE. I even held a coreboot devroom at FOSDEM in 2010, and had a talk on how to RE BIOSes to figure out board specific flash enables. I then was on a long flashrom hiatus from 2010 til earlier this year, when i was solely focused on ARM. But a request for a quick board enable got me into flashrom again. Artificial barriers are made to be breached, and it is fun and rewarding to breach them, and board enables always were a quick fix.

The current changes are still in review at review.coreboot.org, but i have a github clone for those who want immediate and simple access to the complete tree.

To use the ati_spi programmer in flashrom you need to use:

./flashrom -pati_spi

and then specify the usual flashrom arguments and commands.

Current support is limited to the hardware i have in my hands today, namely Rx6xx, and only spans to that hardware that was obviously directly compatible to the Rx6xx SPI engine and GPIO block. This list of a whopping 182 devices includes:
* rx6xx: which are the radeon HD2xxx and HD3xxx series, released april 2007
* rx7xx: or HD4xxx, released june 2008.
* evergreen: or HD5xxx, released september 2009.
* northern island: HD6xxx series, released oktober 2010
* Lombok, part of the Southern Island family, release in january 2012.

The other Southern Islanders have some weird IO read hack that i need to go test.

I have just ordered 250eur worth of used cards that should extend support across all PCIE devices all the way through to Polaris. Vega is still out of reach, as that is prohibitively expensive for a project that is not going to generate any revenue for yours truly anyway (FYI, i am self-employed these days, and i now need to find a balance between fun, progress and actual revenue, and i can only do this sort of thing during downtime between customer projects). According to pci.ids, Vega 12 and 20 are not out yet, but they too will need specific changes when they come out. Having spent all that time instrumenting atiflash, I do have enough info to quickly cover the entire range.

One good thing about targetting AMD/ATI again is that I have been blackballed there since 2007 anyway, so i am not burning any bridges that were not already burned a decade ago \o/

If anyone wants to support this or related work, either as a donation, or as actually invoiced time, drop me an email. If any miners are interested in specifically targetting Vega, soon, or doing other interesting things with ATI hardware, I will be happy to set up a coinbase wallet. Get in touch.

Oh, and test out flashrom, and report back so we can update the device table to "Tested, OK" status, as there are currently 180 entries ranked as "Not-Tested", a number that is probably going to grow quite a bit in the next few weeks as hardware trickles in :)