Showing posts with label OpenBSD. Show all posts
Showing posts with label OpenBSD. Show all posts

Tuesday, May 17, 2016

DataBasin and DataBasinKit 0.9 released

After more than a year of work, finally a new release of DataBasin and its associated framework. This version features a Framework that can be used in threads and the application itself is capable of having concurrent connection classes to SalesForce.com.

On Windows

On OpenBSD


Countless bug fixes (thanks to the bug reports of my colleagues Diego, Moustapha, Matteo + Matteo).

Major new features are:
  • threadable DataBasinKit framework
  • concurrent, interruptible operations (e.g. select vs. update)
  • handle multiple errors as a result of update
  • filter new lines when writing CSVs
  • countless bugfixes, especially in select-identify corner cases

DataBasinKit allows you native connection to SalesForce.com, allowing your application to integrate SOQL queries (SELECT, UPDATE similar operations), be it on Mac (Cocoa) or NetBSD, FreeBSD, OpenBSD, Linux or Solaris as well as Windows (MinGW).
DataBasin itself allows you to perform standard operations in a quick and agile interface: Extract accounts on Linux without the need of Java. Use the unique select-identify feature.

I am proud that Free Software can connect from a Free Software Operating System to a proprietary system and bridge the two worlds, enabling to do administrative work without being constrained to Java on Windows (read: DataLoader). Thanks to the many developers who continue supporting me in the development and keep these fine Operating Systems and tools alive.

Wednesday, January 14, 2015

Monday, February 17, 2014

Tailoring OpenBSD for an old strange computer

I have an ol' OmniBook 800CT. A small, interesting computer, for its time, extremely advanced!
Small form factor, but still a very nice keyboard, something unmatched on modern netbooks. The unique pop-out mouse. The series started out with 386 processor, b&w display and ROM expansions.
The 800CT is one of the latest models: same form factor, SCSI connector, but color screen (800x600) and a hefty Pentium 133Mhz!
But only 32 MB of ram (the kernel report 31 of real mem, 24 avail mem)

Original 5.4 kernel: 9.2M
Custom kernel: 5.0 M

This shrinkage is quite hefty! almost 50%! More than raw disk usage, this new kernel boots faster and leaves  more free memory. Enough more that X11 is now almost usable

How can this be achieved? essentially by removing unused kernel options. If you remove drivers which you know you don't need because you don't have the hardware (and won't use it, e.g. you know you won't plug-in a certain card in the future) then you configure it out, it won't be built and it won't get in your kernel.
On an old laptop with no expansion except the ports and the PCMCIA port it has, this is relatively easy.

To build your custom kernel, follow the OpenBSD FAQ.

The main theory is to take the kernel configuration file, skim over it line by line it and see if you have the hardware, which you know by checking your dmesg. Dmesg shows which devices and drivers were loaded.Remember that you do not modify GENERIC, but a copy of it.

You can automate this with a tool called dmassage: it will parse your GENERIC configuration and produce an optimal tuned version, however it will not work out of the box.
Why? there are drivers which do not compile if other drivers are not present.

I'm unsure if this is really a bug, in my opinion it is at least "unclean" code, however since mostly this kind of extreme driver-picking is not done, it is not fatal and probably won't be fixed.

 If you remove all drivers at once, you won't easily find out one which one breaks, so my suggestion is to remove them in sets. One by-one is surely too tedious, since for each you need to make a build.
  1. remove X drivers
  2. build, if it works, copy the configuration file as a backup
  3. test the kernel, optionally, by booting it
  4. continue removal

Thus, in case of breakage, you can narrow it down to a less options.

If your mahcine doesn't have a certain bus, you may remove all drievrs attached to each. But proceed from the leaves, not the trunk: gradually remove the peripheral drivers before removing the bus support.

In my case, I found that an unremovable driver is:
et*    at pci?                # Agere/LSI ET1310


Remember that you are running an unsupported kernel, if you want support for a problem, better try it with the original kernel, of which you should anyway for safety retain a backup copy during the iterative building process.

Addition:

In X11, which needs to be set to 800x600 8-bit mode, I had to uncomment these lines:
    #Option "progLcdModeRegs" "true"
    #Option "progLcdModeStretch" "true"

Tuesday, June 21, 2011

Battery Monitor now on OpenBSD


The battery monitor for GNUstep of the GAP project, has now basic battery information support by accessing the APM/ACPI driver. Advanced cell information supplied by ACPI is still missing. In any case at least I can see how much juice my OpenBSD laptop has left...

(Tested on my Dell Latitude C600, as always with APM and APCI, your luck with other laptops may vary depending on BIOS information and Kernel support)