On Icaza kissing up to proprietary software

The iPad is better than anything else around, and it's not got much to do with being proprietary. The only serious contenders are F/OSS-based: Android and WebOS.

By saying it does, Miguel is engaging in the same kind of cargo cult that has led Microsoft to try to compete with Apple by copying the wrong things. Take Zune and its closed platform ecosystem, the restrictions on Windows Phone 7 development and so on.

No, Apple has succeeded better than anyone because Steve Jobs is really good at industrial design. By industrial design I do not mean making nice shiny objects. Slapping a fancy 3D interface on a piece of shit is not design; hiring an expensive designer to draw the packaging and enclosure of a shitty product is not industrial design.

It's putting all those things together so that the product is robust, does not frustrate the user, affordable as opposed to cheap, and, most importantly, does something useful for the user.

(Apple products are often seen as way too expensive compared to the competition, but the fact is, for the past 20 years, they've had excellent resell value even a few years after release. How much can you sell a 3 year old Dell laptop? It's probably not even worth the shipping; while you can resell a Macbook that old for a reasonable amount of money. It's not cheap, but it's valuable.)

That's why the battle of specs competitors are trying to wage is incredibly retarded. Take the front facing camera that the iPhone 3 and 3GS were lacking; almost all high end smart phones at the time had them. I had one on my N900. *None* of them had decent software to support it. What good did it make? Entirely pointless.

And again, this has nothing to do with proprietary software. The only way proprietary software serves Apple here is because they have a competitive advantage. But the market is becoming a commodity. The iPhone has less of an advantage (it's still much better than the competition but the gap is closing), so it's going to become pointless, in fact, a hinderance: openness will be an advantage to Android when the playing field levels. The corollary is that Microsoft's fucked, they're not better than Apple now, they could catch up but they will never be significantly better than Android.

On new markets, like that of the iPad that Apple created, it serves Apple right now. In time it will matter less, in the same manner. And again, Microsoft is in trouble.

XML is way too hard for the rocket scientists at EMC

Navicli is the command line tool to configure/query a Clariion SAN. Apparently you need some special license to use it, which is weird but I guess a command line tool is unusual for an appliance that's built on a point-click OS such as the Windows 3.11 underlying this storage system.

I won't go into too many details as to how this C.L.I. sucks; let's just instead pick one obvious way it does.
It conveniently provides an -xml switch. Sweet! you might mistakenly think, I shall be able to reliably parse query results! Alas, no.

In the previous version (6.29.something), it didn't even output well-formed XML. It is evidently way too hard for  a multi-billion dollar company to publish code that respects decade old standards. And after all, you've just spend $200k on that piece of hardware, you wouldn't want code that works, too?

Well they appear to have fixed that (or maybe I just got lucky and didn't trigger the bug recently), and the XML now passes basic checks. But it's still unusable. To wit, here's an excerpt of the output of the getdisk subcommand, which is supposed to list all the disks with all their parameters:


<?xml version="1.0" encoding="utf-8"?>
<CIM CIMVERSION="2.0" DTDVERSION="2.0">
  <MESSAGE ID="877" PROTOCOLVERSION="1.0">
    <SIMPLERSP>
      <METHODRESPONSE NAME="ExecuteClientRequest">
        <PARAMVALUE NAME="CLASSIC CLI" TYPE="string">
          <VALUE>Bus 0 Enclosure 0  Disk 0
<PARAMVALUE NAME="Vendor Id" TYPE="string">
              <VALUE>SEAGATE </VALUE>
            </PARAMVALUE>
            <PARAMVALUE NAME="Product Id" TYPE="string">
              <VALUE>STT30065 CLAR300</VALUE>
            </PARAMVALUE>


At first it looks like a straightforward list of key/value pairs, with added (mostly useless) loose type information. But notice the "Bus 0..." information. Now look at the next instance of it:



            <PARAMVALUE NAME="Prct Busy" TYPE="uint64">
              <VALUE>0</VALUE>
            </PARAMVALUE>




Bus 0 Enclosure 0  Disk 2
<PARAMVALUE NAME="Vendor Id" TYPE="string">
              <VALUE>SEAGATE </VALUE>
            </PARAMVALUE>

That's right, it's a stray printf in the middle of XML output. It's completely unparsable. On top of that, everything is indeed linear, the hierarchy of data is not preserved. For instance, they could have grouped all  Bus 0 items under one element, and then Enclosure 0, and so on; instead it's all listed at the same level. 

Edit: and I forgot to add, the RPM for version 7.30.0.4.74 asks a question in the %postinst section, which appears to break installation through yum. Is there anything those MS-DOS types can't get wrong?

Firmly stupid Linux firmware updating with IBM

IBM boasts of plenty of admin-friendly tools for updating drivers and firmwares. Unfortunately, as usual with administration tools, it looks like they've been packaged by complete retards.

 Apparently they don't like tar.gz, zip, tar.bz2, 7z or even rar, arc or what have you. Nope, the geniuses at IBM are so nostalgic of the good ole DOS days that they decided to resuscitate the very bad scheme of self-unpacking executables.

If that malware-spreading nonsense wasn't bad enough in itself, they made sure that:
 - it required an executable /tmp
 - that unpacking required root privileges most of the time
 - you couldn't specify the temp dir with TMPDIR or anything, really
 - it writes random log files in random places, such as the current directory, without telling anyone, and happily overwriting any file with that name. What if that file happens to be a symlink towards /etc/passwd? Don't worry, IBM's got you covered, it will fuck your system up free of charge.

SELinux policy module for pipslited

Pipslited is the daemon part of the official Linux driver for Epson inkjets. It used to suck quite frankly, but as far as I can tell the latest versions have been improving visibly. Problem is that it hasn't got an SELinux policy module. Oddly I thought there was one but I just realized today that I couldn't print. So I got to work with Slide, the Eclipse-based SELinux policy editor.

This is on Fedora 13, selinux-policy 3.7.19

The code

pipslite.if

## <summary>epson cups module</summary>

Yes it's empty, as usual.

pipslite.te

policy_module(pipslite,1.0.12)

require {
 type fs_t;
 type setroubleshootd_t;
 type cupsd_t;
 type printer_device_t;
}

type pipslite_t;
type pipslite_exec_t;
type pipslite_config_t;
type pipslite_pid_t;
type pipslite_fifo_t;
type pipslite_tmp_t;

domain_type(pipslite_t)

# Access to shared libraries
libs_use_ld_so(pipslite_t)
libs_use_shared_libs(pipslite_t)

miscfiles_read_localization(pipslite_t)

dev_read_urand(pipslite_t)

# Type for the daemon
files_type(pipslite_exec_t)
domain_entry_file(pipslite_t, pipslite_exec_t)

# Type for configuration files
files_config_file(pipslite_config_t)

allow pipslite_t pipslite_config_t:file { getattr read create_file_perms };
allow pipslite_t pipslite_config_t:dir { create_dir_perms };

# Type for PID file
files_pid_file(pipslite_pid_t)

allow pipslite_t pipslite_pid_t:file manage_file_perms;
allow pipslite_t pipslite_pid_t:dir rw_dir_perms;
files_pid_filetrans(pipslite_t,pipslite_pid_t,file)


# Type for temporary files
#
# Probably not necessary, but in case pipslite wants to create
# temp files, it's there and it's secure
files_tmp_file(pipslite_tmp_t)

allow pipslite_t pipslite_tmp_t:file create_file_perms;
allow pipslite_t pipslite_tmp_t:dir create_dir_perms;
files_tmp_filetrans(pipslite_t,pipslite_tmp_t,{file dir})

# We define a new type for the fifo used by cups to connect to pipslite
allow pipslite_t pipslite_fifo_t:fifo_file { read create open };
filetrans_pattern(pipslite_t, var_run_t, pipslite_fifo_t, fifo_file)
allow pipslite_fifo_t fs_t:filesystem associate;
allow pipslite_t pipslite_fifo_t:fifo_file unlink;

# Network connections, incoming
allow pipslite_t self:tcp_socket { bind create setopt listen };
corenet_tcp_bind_generic_node(pipslite_t)

# Makes the init.d script execute in the desired domain
# Without this, it just takes the context of the caller, unconfined typically.
init_daemon_domain(pipslite_t, pipslite_exec_t)

# --- Getting to the point ---
# Pipslite needs to talk to the printer
allow pipslite_t printer_device_t:chr_file { read write open };

# .. and cupsd needs to talk to pipslited
allow cupsd_t pipslite_fifo_t:fifo_file { write open };

# No idea why this is needed, new thing?
allow setroubleshootd_t pipslite_fifo_t:fifo_file getattr;

pipslite.fc

/usr/lib64/pipslite/pipslited -- gen_context(system_u:object_r:pipslite_exec_t,s0)
/etc/pipslite(/.*)? gen_context(system_u:object_r:pipslite_config_t,s0)
/var/run/pipslited.pid -- gen_context(system_u:object_r:pipslite_pid_t,s0)
# This is needed because pipslited doesn't seem to always delete
# the fifo on exit, and it doesn't recreate it if it's already there
/var/run/pipslite[^/.]* gen_context(system_u:object_r:pipslite_fifo_t,s0)

Compiling and installing the module

# service pipslited stop
# ln -s /usr/share/selinux/devel/Makefile .
# make
Compiling targeted pipslite module
/usr/bin/checkmodule:  loading policy configuration from tmp/pipslite.tmp
/usr/bin/checkmodule:  policy configuration loaded
/usr/bin/checkmodule:  writing binary representation (version 10) to tmp/pipslite.mod
Creating targeted pipslite.pp policy package
rm tmp/pipslite.mod tmp/pipslite.mod.fc
# semodule -i pipslite.pp
# restorecon -Rv /etc/pipslite/ /usr/lib64/pipslite/pipslited /var/run/pips* 
# service pipslited start

Wacom Bamboo Touch

Snoopy spotted in Paris

charonnedogportrait
Originally uploaded by docteur_nic

Rue de Charonne.

Retarded coding standards?

I just stumbled upon this strange blog post that appears to affirm that the following code:

#include 
int main() { std::cout << "Hello, world" << std::endl; }

... is full of "errors," according to the poster's interpretation of MISRA C++ and LINT.

Those are not errors in code; those are design flaws in either the spec for the standard or LINT.

1. The “int” in “int main” violates an advisory rule to avoid using built-in types and instead use typedefs indicating the size and signedness of the type, such as int32_t, INT or signed32T.

main(int,char**) returns an int. Not an int32_t or an int16_t depending on the platform, but an int, which happens to be an int16_t, an int32_t or an int64_t depending on the platform. This is Unix semantics. The resulting value is an error code, not an integer meant to be calculated upon and subject to overflow. At worst it's a small binary set, again not subject overflow. It has been so since C and Unix exist. Ignoring it is just strange.

2. The first left shift operator violates a MISRA rule disallowing the use of bitwise shift on signed types, or so it does according to LINT

ostream & operator<< (const char *) is not the bit shift operator. It is an operator alright. It does not, however, perform a bit shift. Therefore, it is not the bit shift operator. The bit shift operator is (for example) int operator<<(int).

Furthermore, the meaning of said operator is clearly defined for signed integers. Why not disallow substraction on unsigned types, while they're at it? That should prevent underflow!

The two left shift operators as a whole are reported to violate the rule disallowing dependence on C operator precedence [and add parenthesis everywhere]

This is simply crazy. This kind of blanket rules are completely, utterly idiotic. '<<' here is much more readable without parenthesis, esp. considering that there is no other operator that could preempt it.

And anyone who's graduated grad school, even last of his class, knows that 1+2*3 == 1+(2*3) != (1+2)*3. And anyone who's graduated from junior high knows that 1/2/3 is fishy. And what about expressions with just one commutative operator? Are we to add parenthesis to 1+2+3?

I don't know who's to blame here, if the LINT tool is really that clueless or if the MISRA standard mandates this behaviour, but I can't begin to understand how you can ignore long standing (25+ years!) C and C++ idioms. If they don't like operator overloading, why don't they remove them altogether and call it Java?