Over the years I've come to love and loathe the web, it's technologies and it's chaos. As with any evolving (in the darwinian sense) technology, there'll always be situation where your desktop environment just not (yet) provides what is needed to consume the leaves of a particular technology (no I'm not a vegetarian).
So what does actually work for me with my mostly standard opensolaris install from the point of view that I'm mostly a consumer of opensolaris?
browsing: firefox 3.5.7 works great. however, firefox is delivered with the OS distribution. Not much of a problem since I suck up the bits from the /dev repository, but still out of sync: What if a critical vulnerability arose in firefox? I'd be stuck waiting for new bits from /dev, which come about every two weeks, but that would put my window of vulnerability at a worst case of two weeks. Ideally, the mozilla foundation would host a pkg server which would allow you to suck up their freshest bits. setting up a pkg mirror is increadibly easy, I doubt they'd have a hard time dealing with the added load. (besides, how much opensolaris clients are out there anyway?).
On a separate thought, If I were to run a pkg server for my own domain with the intent of providing rapid, repeatable installs and updates from various sources, how would I infact provide a single pkg-space comprising several components with components from different sites? Worth looking into.
Generally, the browsing experience is very nice (I can do my work). With flash and java most of my needs are covered. I am very very content with these plugins: it was a long wait, but boy was it worth it. Truth is, I do occasionally run into silverlight components (haven't seen adobe air in fact!) I expect javafx to "just work" actually. In fact just hopping over to jjavafx shows it just works. Video plugins are pretty decently covered by totem, especially if you get some more of those gstreamer-plugins from say fluendo.
Coming back to the point I made earlier: fluendo provides for it's own update mechanism: codeina. Honestly: that ticks me off: I would say it should be a given that the update and install mechanisms should be mostly the same. Any deviation from that is in my opinion a significant barrier to enter. Let's look at the example of the pkg.sun.com/extra repository... For every user, issue a certificate. Expire the certificate once the license policy agreement expires (which is what fluendo seems to do for their free plugin) and Bob's your uncle. No new registration: no more updates. Then again: how would you provide for a "shop" like model where the certificates determine what you can see/download? (As is the case with fluendo and their paid for plugins which give added value on top of the free ones they provide?).
Other plugins which make my life on the web much more bearable: ad block plus, noscript. Good that they stopped pestering each other as well. They just work on opensolaris.
A thing about developing technology in the web 2.0 arena that greatly bothers me is the clash of the various titans in this space: the facebooks, flickr's, google's all add value to the internet for me. However, it seems as if they are hell bent on keeping the other ones out. Mining the user seems to quickly turn to be the priceless commodity (or fool's gold?) they are all after: you don't pay for the service you get, but the costs of running the service are (more than) covered by the knowledge about yourself that you surrender. Make no mistake: your identity or parts of it are monetised and sold off to the highest bidder. The obvious monetization here is targeted advertisement, which is what made google big, but there's more contenders: for a startup, getting to an IPO is a worthy goal in itself (as proven a few years ago now by google)
Google especially seems like a sink/magnet/strange attractor: Lot's of stuff goes in: my blog, my analytics, my rss reading, my mail, but none seems to come out at least not very easily. Ok fair: the degree of openness to the end user at google's products is not so bad compared to others: I read my mail locally via imap (thunderbird). Last time I checked hotmail didn't (but that was a long time ago). I managed to get my google calendar out as well, but do needed to digg around to find the appropriate plugin. There's more stuff that you can get out, but don't tell me it's easy let alone guaranteed.Bottom line: you're lucky if you get your data out, but you'll usually have to have a fair bit of knowledge of the underlying technology.
Come to this: what I like very much are tools who tie it all together: pidgin excels at joining my various identities together: I've got facebook, msn, google chat, company im, and a few more all tied into one neat little interface that behaves by and large the same for each and every protocol. Fantastic: If I were to nominate folks for the nobel prize... (only slightly kidding). Other tools which provide this kind of glue between the various services out there: drivel. gtg. thunderbird. openoffice. And a much overlooked feature of gnome: the clock: providing time, weather for various places around the globe. Haven't seen such a simple solution coming from microsoft or apple. The clock widget on os X does mostly the same, but seriously, I don't need all those bells and whistles, let alone the screen real estate it would consume for three or four clocks with a weather forecast to it. I just want tools that work, do their thing and don't get in the way of me being productive.Various chat protocols exist: facebook had (it changed a few weeks ago) a private chat protocol: they changed: thank you very much. No more hassling to dig up and build the purple plugin which enables facebook chat in pidgin. Kudos to the guys who wrote the plugin: admirable job, but reality is that you always played catch up. (Still goes for msn though).
So what then am I missing? proper support for my ATI Radeon. Not being able to run compiz is a major gripe. My point of view: intel gets it. NVidia gets it. AMD doesn't. Intel's worked hard to align with major opensource projects and I feel it's only fair to say that this will (in my opinion) pay out: support for their latest and greatest cpus: it's already in opensolaris (and I would presume in linux), and not only just the "getting things running" good enough kind of stuff: nope: their work on opensolaris made sure that a lot of the distinguishing features of their cpus are working. To a lesser extent this applies to NVidia as well, obviously with a lot smaller scope. AMD? They insist on chucking a binary over the fence every now and then for linux if you want more than the absolute basic functionality which you can find in the open source driver. It's closed. It won't help you. Rest assured, I'm not inclined to get an AMD graphics card or anything that has AMD in it (think laptop). Not now, not in the near future. It's as simple as that.
Another thing is mono and the development stuff around it (gtk-sharp etc) and quite a set of nice applications like F-spot, tomboy etc which are applications which fill a hole. Posting to flickr is a pain at the moment. gnome-sticky notes are ok, but no match for tomboy. And what about moonlight as an open source silverlight plugin? Honestly, I share the concerns about the entanglement between novell and microsoft and possible consequences if microsoft decided to pull the plug in some form or another (I strongly believe they can, not so sure if they would truly dare to do so). Also the thought of having mono as a first (or even second) class citizen in solaris would make my life a lot easier. I'm happy to run the risk of having to part with the applications running on mono when the time comes. yikes.bitter after all;-)
an attempt at documentation of my ongoing struggles with solaris and opensolaris on x86. I believe strongly in the (public) documentation of trials, struggles and failures, even more so than in the documentation of success: With a long standing commitment to solaris, looking for answers and just finding "I tried it on distibution 'X' and it worked for me" is not very informative.
Tuesday, February 23, 2010
Darn. spotted.
I had hoped noone would actually read this garbage collection of random errors, mistakes and blatant exhibition of missing knowledge.
Sunday, February 14, 2010
pidgin facebook plugin for opensolaris: make way for xmpp support at facebook!
I only recently noticed that the facebook plugin for opensolaris in the /contrib repository stopped working. A little digging:
$ pkg info pidgin-facebookchat
Unable to locate key '/export/home/ah115678/Downloads/OpenSolaris_extras.key.pem' for publisher 'extra.sun.com' needed to access 'https://pkg.sun.com/opensolaris/extra/'.
Unable to locate certificate '/export/home/ah115678/Downloads/OpenSolaris_extras.certificate.pem' for publisher 'extra.sun.com' needed to access 'https://pkg.sun.com/opensolaris/extra/'.
Name: pidgin-facebookchat
Summary: Facebook chat support for Pidgin
Description: Facebook chat support for Pidgin
Category: Applications/Internet
State: Installed
Publisher: contrib.opensolaris.org
Version: 1.50
Build Release: 5.11
Branch: 0.101
Packaging Date: April 30, 2009 06:41:16 PM
Size: 94.57 kB
FMRI: pkg://contrib.opensolaris.org/pidgin-facebookchat@1.50,5.11-0.101:20090430T184116Z
so version 1.50. That might explain why... The most current version is 1.64.
I tracked down the creator of the original 1.50 package via the source juicer an contacted him to let him know. Good news: he's working on it!
Additionally, I found that facebook moved to xmpp/jabber protocol, so it's no longer needed to have a dedicated plugin...
wonderful solution I'd say
$ pkg info pidgin-facebookchat
Unable to locate key '/export/home/ah115678/Downloads/OpenSolaris_extras.key.pem' for publisher 'extra.sun.com' needed to access 'https://pkg.sun.com/opensolaris/extra/'.
Unable to locate certificate '/export/home/ah115678/Downloads/OpenSolaris_extras.certificate.pem' for publisher 'extra.sun.com' needed to access 'https://pkg.sun.com/opensolaris/extra/'.
Name: pidgin-facebookchat
Summary: Facebook chat support for Pidgin
Description: Facebook chat support for Pidgin
Category: Applications/Internet
State: Installed
Publisher: contrib.opensolaris.org
Version: 1.50
Build Release: 5.11
Branch: 0.101
Packaging Date: April 30, 2009 06:41:16 PM
Size: 94.57 kB
FMRI: pkg://contrib.opensolaris.org/pidgin-facebookchat@1.50,5.11-0.101:20090430T184116Z
so version 1.50. That might explain why... The most current version is 1.64.
I tracked down the creator of the original 1.50 package via the source juicer an contacted him to let him know. Good news: he's working on it!
Additionally, I found that facebook moved to xmpp/jabber protocol, so it's no longer needed to have a dedicated plugin...
wonderful solution I'd say
Labels:
facebook,
jabber,
opensolaris,
pidgin,
xmpp
gtg and hamster
On another note. hamster (from the opensolaris.org repository) and gtg work like a charm together! All you need to do is activate the co-delivered plugin in gtg's preferences... and off you go.
Labels:
gnome,
gtg,
hamster,
opensolaris
getting thing gnome for opensolaris
I've had my mind set on a task manager for gnome for sometime already. GTG seems like a nice quick and dirty tool which doesn't get in the way of actually getting things done. Getting it to actually work was another. Turns out this is rediculously simple:
Apart from python 2.6 there's just 1 single dependency: configObj.
To install: download (I chose the zip file).
unzip, modify the setup.py to have as a first line:
#!/usr/bin/env python
then
$ pfexec ./setup.py install
done.
For gtg: download
gzcat gtg* |tar xvf -
cd gtg...
$ pfexec ./setup.py install
All done.
Installs into /usr/bin
so
$ gtg
and on your way!
Apart from python 2.6 there's just 1 single dependency: configObj.
To install: download (I chose the zip file).
unzip, modify the setup.py to have as a first line:
#!/usr/bin/env python
then
$ pfexec ./setup.py install
done.
For gtg: download
gzcat gtg* |tar xvf -
cd gtg...
$ pfexec ./setup.py install
All done.
Installs into /usr/bin
so
$ gtg
and on your way!
Labels:
configObj,
gnome,
gtg,
opensolaris
Sunday, March 29, 2009
building enblend: another step closer to hugin?
Don't know why I just don't give up. I *need* to get my photo stuff into hugin I suppose.
So, having a go at building enblend; yet another dependency for hugin.
Downloaded and
#./configure
[..]
configure: error: libxmi is required to compile enblend.
so. Download libxmi and see what that brings us:
#./configure
# make
# make install
And works! Kudos to the developers of both libxmi and opensolaris... clean, portable code and a build environment that's starting to make sense of linux stuff!
Another go at building enblend (with LDFLAGS=-L /usr/local/lib) now fails for sake of boost headers missing. Which is not too bad doing this now, as hugin lists it as a requirement as well.
Let's have a go at those.
# ./configure
passed!
# make
[ ... quite a few errors relating to python stuff, but I'll leave it at that for now; just hoping python isn't used down the road ...]
#make install
works as well!
update 30/03: Managed to get ./configure to complete. However, make struggles. I filed an incident report at the good soureforge-folks of the project team:
See http://solaristerror.blogspot.com/2009/01/pidgin-facebook-plugins-and-opensolaris.html for details.
So, having a go at building enblend; yet another dependency for hugin.
Downloaded and
#./configure

[..]
configure: error: libxmi is required to compile enblend.
so. Download libxmi and see what that brings us:
#./configure
# make
# make install
And works! Kudos to the developers of both libxmi and opensolaris... clean, portable code and a build environment that's starting to make sense of linux stuff!
Another go at building enblend (with LDFLAGS=-L /usr/local/lib) now fails for sake of boost headers missing. Which is not too bad doing this now, as hugin lists it as a requirement as well.
Let's have a go at those.
# ./configure
passed!
# make
[ ... quite a few errors relating to python stuff, but I'll leave it at that for now; just hoping python isn't used down the road ...]
#make install
works as well!
update 30/03: Managed to get ./configure to complete. However, make struggles. I filed an incident report at the good soureforge-folks of the project team:
See http://solaristerror.blogs
adhoc wireless, dhcp-serving and nat'ing with opensolaris
Lately, I've been in spots with multiple laptops and only wired-internet.
Time to fix that I'd say and take control: create a wireless ad-hoc network, with my laptop as the initiator and have the other laptops connect through me.
creating a wireless ad-hoc network is remarkably simple:
in preparation, I first disabled nwam (as my usual mode of operation)
#svcadm disable nwam
#svcadm enable physical:default
Create an ad-hoc wireless network with SSID "twitternet" (check first that the SSID doesn't exist yet):
# dladm connect-wifi -e twitternet -c -b ibss iwk0
Next plumb the TCP/IP part of it.
Not needed yet, but useful for DHCP is to add an entry for 192.168.0.0 to /etc/inet/netmasks.
# ifconfig iwk0 plumb
# ifconfig iwk0 192.168.0.1 netmask + broadcast + up
So, now an adhoc wireless network has been created.
In order to setup a DHCP server and provide some automated network services for generic clients:
Ok, I "cheated", and used the GUI to do the initial configuration of the macros etcetera: /usr/sadm/admin/bin/dhcpmgr. You should be able to achieve the same with:
# dhcpconfig -D -r SUNWfiles -p /var/dhcp -h files
dhcpconfig/dhcpmgr will setup with an ascii-file database in /var/dhcp and update /etc/hosts with the names. It'll also create some macros with as much stuff as it can find out about your network. (check the man page for dhcpconfig; it has a nice table).
With the dhcpmgr GUI, create a network (192.168.0.0 in my case) and set it up to your liking (no-nonse config, I just assigned a static router: 192.168.0.1 and in the end the network macro. I'll look into using RIP another time).
This can ofcourse also be done with pntadm.
As the network macro did not include the external DNS server, and I have not setup my laptop to run one, I checked the localhost macro, and noticed that it nicely implemented the DnsDomain and DnsServer options, pre-populated with the entries from /etc/resolv.conf. (that's why it was useful to put an entry into /etc/inet/netmasks) Nice!
As however the 192.168.0.0 network had the 192.168.0.0 macro assigned to it, the clients would not pick up the DnS* options. I opened the properties for the 192.168.0.0 macro and added a field "Include" with value "localhost"; Now the localhost macro is also provided to the clients!
All done with dhcp-server configuration (a 2 minute job really)
In order to prevent the dhcp-server from resonding to DHCP requests on all interfaces, I added a line to /etc/inet/dhcpsvc.conf:
INTERFACES=iwk0
As a final check:
1) is the wireless adhoc bit setup?
# dladm show-wifi
LINK STATUS ESSID SEC STRENGTH MODE SPEED
iwk0 connected twitternet none good b 54Mb
#
is iwk0 up and does the ipaddress match the router-ipaddress you're handing out?
# ifconfig iwk0
iwk0: flags=201100843 mtu 1500 index 2
inet 192.168.0.1 netmask ffffff00 broadcast 192.168.0.255
ether 0:1d:e0:19:e9:25
#
# dhtadm -P
Name Type Value
==================================================
192.168.0.0 Macro :Subnet=255.255.255.0:Router=192.168.0.1:Broadcst=192.168.0.255:Include=localhost:
localhost Macro :Include=Locale:Timeserv=127.0.0.1:LeaseTim=86400:LeaseNeg:DNSdmain="local":DNSserv=XX.YY.40.25 XX.YY.35.25:
Locale Macro :UTCoffst=3600:
#
next connect the network cable to my wired-network port and
# ifconfig e1000g0 dhcp start
# ifconfig e1000g0
e1000g0: flags=201104843 mtu 1500 index 3
inet XX.YY.27.76 netmask fffff800 broadcast XX.YY.31.255
ether 0:a0:d1:a2:f1:e3
Almost done!
run routeadm and make sure ipv4 routing and forwarwarding are enabled. (Usually, forwarding is disabled. enable with "routeadm -e ipv4-forwarding ; routeadm -u" where needed.
One more last hurdle: you'll need NAT on your wired port to have the clients utilise the single ip-address you've been given:
enable ipfilter (in a blank configuration like mine, ipfilter requires the network/physical:default service, so that's why it needs to be enabled).
# svcadm enable ipfilter
Check that you don't have any NAT mappings yet:
# ipnat -l
and if needed: clean them out with:
# ipnat -C ; ipnat -F
Next, setup a nat mapping:
# echo "map e1000g0 192.168.0.0/24 -> 0.0.0.0/32" | ipnat -f -
Enable the dhcp server:
# svcadm enable dhcp-server
do a final check:
# svcs -x
If everything's running (i.e. ipfilter, dhcp-server mainly) you should be ready to serve the rest of the room.
Ofcourse, you'll need additional (reverse) port mappings if your clients would like to perform server tasks, but that's beyond this scope (besides, my clients sofar were pretty bog standard windows users and laptops, so no fancy stuff needed).
Time to fix that I'd say and take control: create a wireless ad-hoc network, with my laptop as the initiator and have the other laptops connect through me.
creating a wireless ad-hoc network is remarkably simple:
in preparation, I first disabled nwam (as my usual mode of operation)
#svcadm disable nwam
#svcadm enable physical:default
Create an ad-hoc wireless network with SSID "twitternet" (check first that the SSID doesn't exist yet):
# dladm connect-wifi -e twitternet -c -b ibss iwk0
Next plumb the TCP/IP part of it.
Not needed yet, but useful for DHCP is to add an entry for 192.168.0.0 to /etc/inet/netmasks.
# ifconfig iwk0 plumb
# ifconfig iwk0 192.168.0.1 netmask + broadcast + up
So, now an adhoc wireless network has been created.
In order to setup a DHCP server and provide some automated network services for generic clients:
Ok, I "cheated", and used the GUI to do the initial configuration of the macros etcetera: /usr/sadm/admin/bin/dhcpmgr. You should be able to achieve the same with:
# dhcpconfig -D -r SUNWfiles -p /var/dhcp -h files
dhcpconfig/dhcpmgr will setup with an ascii-file database in /var/dhcp and update /etc/hosts with the names. It'll also create some macros with as much stuff as it can find out about your network. (check the man page for dhcpconfig; it has a nice table).
With the dhcpmgr GUI, create a network (192.168.0.0 in my case) and set it up to your liking (no-nonse config, I just assigned a static router: 192.168.0.1 and in the end the network macro. I'll look into using RIP another time).
This can ofcourse also be done with pntadm.
As the network macro did not include the external DNS server, and I have not setup my laptop to run one, I checked the localhost macro, and noticed that it nicely implemented the DnsDomain and DnsServer options, pre-populated with the entries from /etc/resolv.conf. (that's why it was useful to put an entry into /etc/inet/netmasks) Nice!
As however the 192.168.0.0 network had the 192.168.0.0 macro assigned to it, the clients would not pick up the DnS* options. I opened the properties for the 192.168.0.0 macro and added a field "Include" with value "localhost"; Now the localhost macro is also provided to the clients!
All done with dhcp-server configuration (a 2 minute job really)
In order to prevent the dhcp-server from resonding to DHCP requests on all interfaces, I added a line to /etc/inet/dhcpsvc.conf:
INTERFACES=iwk0
As a final check:
1) is the wireless adhoc bit setup?
# dladm show-wifi
LINK STATUS ESSID SEC STRENGTH MODE SPEED
iwk0 connected twitternet none good b 54Mb
#
is iwk0 up and does the ipaddress match the router-ipaddress you're handing out?
# ifconfig iwk0
iwk0: flags=201100843
inet 192.168.0.1 netmask ffffff00 broadcast 192.168.0.255
ether 0:1d:e0:19:e9:25
#
# dhtadm -P
Name Type Value
==================================================
192.168.0.0 Macro :Subnet=255.255.255.0:Router=192.168.0.1:Broadcst=192.168.0.255:Include=localhost:
localhost Macro :Include=Locale:Timeserv=127.0.0.1:LeaseTim=86400:LeaseNeg:DNSdmain="local":DNSserv=XX.YY.40.25 XX.YY.35.25:
Locale Macro :UTCoffst=3600:
#
next connect the network cable to my wired-network port and
# ifconfig e1000g0 dhcp start
# ifconfig e1000g0
e1000g0: flags=201104843
inet XX.YY.27.76 netmask fffff800 broadcast XX.YY.31.255
ether 0:a0:d1:a2:f1:e3
Almost done!
run routeadm and make sure ipv4 routing and forwarwarding are enabled. (Usually, forwarding is disabled. enable with "routeadm -e ipv4-forwarding ; routeadm -u" where needed.
One more last hurdle: you'll need NAT on your wired port to have the clients utilise the single ip-address you've been given:
enable ipfilter (in a blank configuration like mine, ipfilter requires the network/physical:default service, so that's why it needs to be enabled).
# svcadm enable ipfilter
Check that you don't have any NAT mappings yet:
# ipnat -l
and if needed: clean them out with:
# ipnat -C ; ipnat -F
Next, setup a nat mapping:
# echo "map e1000g0 192.168.0.0/24 -> 0.0.0.0/32" | ipnat -f -
Enable the dhcp server:
# svcadm enable dhcp-server
do a final check:
# svcs -x
If everything's running (i.e. ipfilter, dhcp-server mainly) you should be ready to serve the rest of the room.
Ofcourse, you'll need additional (reverse) port mappings if your clients would like to perform server tasks, but that's beyond this scope (besides, my clients sofar were pretty bog standard windows users and laptops, so no fancy stuff needed).
Labels:
adhoc wireless,
dhcp-server,
dhcpmgr,
dhtadm,
in.dhcpd,
ipf,
ipfilter,
ipnat,
opensolaris,
pntadm
Subscribe to:
Posts (Atom)