This is an Atom formatted XML site feed. It is intended to be viewed in a Newsreader or syndicated to another site. Please visit Atom Enabled for more info.
The Giant MCR was produced from 1997-2000; a short production run as the UCI banned monocoque and other non-parallelogram frames in 1998; essentially destroying frame innovation to this day.
This project is aimed at taking this 1998 MCR Two frame and updating it with the best modern cycle engineering of today. The bicycle industry is inundated with marketing over engineering - so this is no easy task.
What does appear to be a genuine innovation is SRAM's yaw-angle front deraileur. Rather than simply tracking in-and-out, this also pivots - creating a fan-angle tracking the chain across the cassette.
We are sold on this; and thus have ditched the Shimano for SRAM. The SRAM derailer; unfortunately; has a much longer mount/pivot quite quite different to the Shimano - necessitating a custom hanger. The deraileur must fit within the recess in the frame; and whereas with a tube frame where you could simply bend a hanger and/or adjust the mechanism to fit; that is not possible within the limitations of the monocoque.
We started with the open source CAD site, GrabCAD and found a Deraileur Hanger. Unfortunately, this design uses Solidworks, a properietry solution; and incompatible with FreeCAD.
A bunch of iterations later; printed and tested with filament; we're confident we're ready for a production run. Interestingly, none of our prototypes have proven strong enough to actually work in the field - the small amount of flex induced when attempting to shift to the top chainring means we've not actually been able to confirm with static testing.
If you're an industry participant we've reached out to for CNC/3D printing; you may download our STL.
TBD
Oracle are doing these CodeCard devices at their trade shows at the moment. These are actually quite a nifty piece of kit: an ESP-12F (not quite the gruntier ESP32) married to an e-paper display with a couple of buttons to trigger events (short + long holds on A, B buttons - 4 combos) that will shuffle a slideshow of business-card like templates across this display by going out to the interwebs for some basic JSON and then rendering it on the chip.
Since it's all a bit of a wheeze, one of our Australian-local Oracle colleagues has released the code here. I've not really spent much time on Arduino ecosystem, so this seemed like an opportunity to purview the consumer face of IOT (Internet Of Tat). There are some awesome cross-compiler tools for AVR-based chips and it should be quite possible to utilise a classical C/Makefile environment to progress, but for my first foray, I've gone with the Arduino IDE (which ironically since we're discussing Oracle is a Java application). There is a great cheat sheet which will get you up and running; since I on occasion hang at OzBerryPi, I got quickly up to speed with this with some friendly advice at their last event - note to noobs; you have to restart Arduino IDE each time you download a plugin (seems Java reflection hasn't arrived yet - or perhaps Windoz developers maintain upstream Arduino IDE).
There are two facets to the delivered application; the firmware which makes WiFi calls to endpoints to receive and render the JSON; and a configurator which allows you to save the WiFi ESSID and these endpoint URLs. To reflash the firmware, you need the AruinoIDE, and the application source code. To simply save the wifi info, there is a configuration script. The one in the codebase is a little esoteric; and really only designed for Oracle staff to flash devices at exhibition spaces. Have a crack at these here:
# WiFi setup - you may need to hotspot via your phone if out and about ... essid = XXX secret = xxx [a-short] url = http.... # can set url 'method' (dunno why - it's probably always GET # can set url 'fingerprint' the TLS fingerprint for host validation # fingerprint = # method = [a-long] url = http... [b-short] url = http... [b-long] url = http...
#!/usr/bin/python3 # initialise modules.. import binascii, os, serial, sys, time, warnings import serial.tools.list_ports from art import * from configobj import ConfigObj from optparse import OptionParser def command(tty, cmd, bufsize=2048, wait=1): """ send a command to codecard """ tty.write(b'%s\r\n' % cmd.encode()) # write bytes ... time.sleep(wait) print(tty.read(bufsize)) def read(tty, buf='', chunksize=200): """ consume characters from serial tty """ exit = 0 while exit < 2: more = tty.read(chunksize) buf += more exit = len(more) == 0 and exit + 1 or 0 return buf HELP = ''' ====================================================== PURPOSE: Code Card Configurator will update your Code Card configuration settings and perform button 'A' shortpress test.. DIRECTIONS: 1. Plug-in your Code Card 2. Turn on the Code Card (i.e. via hardware power switch) 3. Press 'Enter' to start the process 4. On your Code Card, perform simultaneous button 'A+B' shortpress to boot the Code Card into Configuration Mode Your card will be automatically configured - progress will be logged to stdout WHEN READY: Ensure steps 1&2 are complete, then.. Press Enter to continue... FLASHING CODECARD INSTRUCTIONS: 1. Plug-in your Code Card 2. Set up tty (Arduino IDE [Tools]/[Port]) /dev/ttyUSB0 3. Open tty (Arduino IDE [Tools]/[Monitor]) 4. Turn on the Code Card (i.e. via hardware power switch) 5. Press and hold button A until 5 seconds after the following output is displayed: Shuting down... Shuting down... 6. Flash the device (Arduino IDE [Sketch]/[Upload]) ''' parser = OptionParser(usage=HELP) parser.add_option('-c', '--config', default='~/.codecardrc', help="Configuration inifile (~/.codecardrc)") (options, args) = parser.parse_args() config = ConfigObj(os.path.expanduser(options.config)) # menu/header.. print ("\r\n") strTitle=text2art("CodeCard") print(strTitle, "Oracle Code Card Configurator...\n") #print(HELP) input(" Press Enter to configure the CodeCard...") # list all serial ports.. print ("\r\nENUMERATING PORTS:\r\n") for p in serial.tools.list_ports.comports(): print (" Port Details:") print (" Device: " , p.device) print (" Description: " , p.description) # identify our code card by the `CP210x` string in the port description.. # win: "Silicon Labs CP210x USB to UART Bridge" # mac: "CP2104 USB to UART Bridge Controller" codecard_port = [ p.device for p in serial.tools.list_ports.comports() if 'Silicon Labs CP210x USB to UART Bridge' in p.description or 'CP2104 USB to UART Bridge Controller' in p.description ] # exceptions.. if not codecard_port: raise IOError("No Code Card found !!") if len(codecard_port) > 1: warnings.warn('Multiple Code Cards found !! - Using the first one..') # code card port details.. print ("\r\nCODE CARD FOUND !!") time.sleep(1.5) print ("CODE CARD PORT DETAIL:") print (" " , codecard_port) ser = serial.Serial(codecard_port[0]) print (" " , ser) ser.close() # configure the serial connection to our code card.. ser = serial.Serial( port=codecard_port[0], baudrate=115200, timeout=5, ) s = ser.read(1488) # convert our buffer content to string.. s = str(read(ser, s))[2:-1] # parse buffer content for confirmation that we're in config mode.. if s.find('developer.oracle.com/codecard') != -1: print ("\r\nCODE CARD READY !!") time.sleep(3) print ("DEBUG - CONFIG MODE BUFFER:") for line in s.split('\r\n'): print(line) print ("\r\nCONFIGURING WIRELESS:") command(ser, "ssid=%s" % config['essid']) command(ser, "password=%s" % config['secret']) print ("\r\nCONFIGURING END POINTS:") for key in config.sections: button = "%s%i" % (key[0], key.endswith('short') and 1 or 2) command(ser, "button%s=%s" % (button, config[key]['url'])) for slot in ('fingerprint', 'method'): try: command(ser, "%s%s=%s" % (slot, button, config[key][slot])) except KeyError: pass #command(ser, "restart", 240, 5) #command(ser, "ls", 661) print ("\r\n") print ("SHORTPRESS BUTTON A..") print ("DEBUG - BUTTON PRESS BUFFER:") command(ser, "shortpressa", 500) print(read(ser, b'', 100)) else: print ("\r\n") print ("CODE CARD NOT READY IN CONFIG MODE") print ("QUITTING..")
Obviously, the core thing you're aiming for tinkering with the CodeCard, is what it receives back from it's WiFi calls in response to button presses. Oracle's solution/demo (and the delivered app) is something hosted on Oracle Cloud and they give some excellent documentation on how to spin up an instance, run docker, and deploy your app into a container. It all makes my head hurt! Instead you might like to try something like this I threw together using Bottle - the task isn't big enough to warrant the big brother - Flask.
#!/usr/bin/python3 from bottle import hook, route, run, request, response, static_file def img_url(fname): #return "%s/static/%s" % (request.url.endswith('/') and request.url[:-1] or request.url, fname) return 'http://10.1.1.22:8080/static/%s' % fname @hook('after_request') def application_json(): response.headers['Content-Type'] = 'application/json' @route('/static/') def server_static(filepath): return static_file(filepath, root='./static') @route('/') def default(): return { # 1-11 "template": "template11", "title": "Alan Milligan", "subtitle": "Chief Automation Officer", "bodytext": "This is the body", "icon": img_url("alan-grey-128.bmp"), # OPTIONAL ... # "backgroundColor": "[white|black]", # "badge": [0-100] It will override the icon "badge": "", # "backgroundImage": "[oracle|codeone | BMP url]" Only for templates that have backgrounds # "fingerprint": "" The SHA-1 signature of the server containing the custom icon or backgroundImage URL. } @route('/funny') def funny(): return { "template": "template1", "title": "Alan", "subtitle": "Resident hellraiser", "bodytext": "Making Jack Nicholson look like a schoolboy", "icon": img_url("alan-jester-64.bmp"), "badge": "" } @route('/rambling') def rambling(): return { "template": "template1", "title": "Alan Milligan", "subtitle": "Last Bastion Network", "bodytext": "BastionLinux, DevOps Solutions and Consulting, Continuous Integration and Delivery, Software Development, Amazon Web Services", "icon": img_url("alan-grey.bmp"), "badge": "" } @route('/brief') def brief(): return { "template": "template3", "title": "Alan Milligan", "subtitle": "Chief Automation Officer", "bodytext": "http://linux.last-bastion.net", "backgroundColor": "white", "icon": img_url("bastionlinux-icon.bmp"), "badge": "", } @route('/background') def background(): return { "template": "template8", "backgroundColor": "white", #"backgroundImage": "oracle", # codeone|oracle "backgroundImage": img_url("bastionlinux-bg.bmp"), # codeone|oracle } run(host='0.0.0.0', port=8080)
So you've got this far and you're still with us! You've now reached the bit where the doddle is now completely over! You see, it turns out the actual flashed firmware is more buggy than an Amish conveyance - outside of what Oracle demonstrates at least. The actual software suite does rather reek of a university project rather than a demonstration of best in class design for this hardware platform (but we'll not dwell on this as it is a wheeze after all). But this does lead to exasperation when figuring out and correcting some quite consequent failures.
Silly of me I know; but I aggressively downloaded the latest dependency libraries. The main workhorse, ArduinoJSON has had a major points release from 5.x to 6.x. I had to upgrade the codebase to support this. To be fair, Oracle do state the 5.x in setting up your ArduinoIDE; but I abhor ossification in software projects.
Next, the entire HTTP client layer was completely broken. Oracle have hard-coded all their images into the firmware so that no web requests are necessary to render them; they thus don't see any of the image download/rendering problems. But not only this; the actual HTTP end-point requests are also incorrect. Alas for the ESP chipset, it completely does not help itself; the delivered ESP8266 HTTP library suite is laughably simplistic: it's nothing more than File/Stream IO methods; there is no additional layer for HTTP headers, payload; Cookies; Response objects etc - these are all left up to the application; and here is a classic example of this overwhelming the developer.
I had to make a number of critical changes to fix basic HTTP calls; and I had to fix the responses to accept both HTTP 1.0 and HTTP 1.1 replies - I think there is a strong lesson here that when dealing with these hobbyist chipsets, you should enter the fray with very low expectations of what the SDK's will have for you.
One last observation is that it would seem the e-paper display unit is actually natively expected to be mounted in portrait; all of your images need to be rotated 90 degrees to render properly. This has an interesting corollary in that I'm still baffled as to exactly which corner is 0,0. The third-party graphics rendering library (Adafruit GFX) is nothing compared to the heyday of Sun CDE and creates random black backgrounds behind images, places them many pixels out of place regardless of where you attempt to anchor them.
I would not describe myself as any expert, having only played for a day or so; but I do have the card able to be fully independently branded. I have a pull request here or you can just clone my fork such that you too can get at least as far as I have ...
One should never look a gift horse in the mouth; and this is actually a very expensive and capable piece of kit as a corporate giveaway. Oracle have provided the end-to-end set of tools to both exploit it and to readily interactively discover how you might bring a simple consumer electronic product to market. The software suite, while agricultural, provides you with all of the necessary insight to own whatever project you can think to do with the card. I suspect I'm going to keep one in my bag and shamelessly use on a lanyard doing the rounds at conferences - for the next few months at least!
Plone 5.2 is the first release to get to Zope 4; and thus back to the head/latest releases of a large number of Python modules in the stack. Prior to this, we've had (say) 2.2.x for Plone 4 and 2.5.x for Plone 5; and it's been a complete nightmare.
Legacy Archetype-based products - while technically supported; are not included/tested within Plone 5 infrastructure (even the test case machinery is missing) - with obvious spectacular effect on ZODB migration. With a rather precipitous decline in company's/maintainers continuing to participate in this space, it is unlikely original maintainers will be upgrading these to play with Plone 5. The beauracracy around (whether it's even possible) you assuming maintainership and releasing onto PyPi for buildout-based deployments is - err zero.
Any python code (bytecode) within your ZODB needs to be identified and ported to Python 3 .
We ship/support the OpenStack toolchain, and have a decent Jenkins toolchain. We auto-generate JJB jobs to test Python/RPM packages out of KGS suite(s) as identified via classical buildout suites for example.
Because we ship via RPM, we have full lifecyle and patch management outside of what may be available on PyPi.
Giant Cadex CFR-1 in immaculate condition for its age. The frame is bonded carbon and a dream to ride. Comes with the coolest Spinergy Rev-X wheels. You wont find any in better condition.
This is the 1993 model, an absolute classic as it is the first of the successful CFR range. The CFR-1 is the top of the range complete with Shimano 600 groupset.
Spinergy Rev-X wheels are icons of 1990's cycling until they were banned by the UCI in 2001 as they failed a new safety standard, of which there are conspiracy theories. Apparently the Rev-X's come in four generations, with this pair being the last. I am not entirely sure if these are superstiffs; but they do have an additional finger of carbon layup on the inside of each spoke.
Spinergy also sold stiffeners, known as X-Beam's for these wheels which supposedly improves lateral stiffness. An X-Beam was an additional plastic brace that wedged between each spoke. These came in three different colours for different tensions provided. There is quite some controvesy as to whether these are effective - with a good technical discussion here
It seems these are incredibly difficult to find these days, but can be 3D printed based upon an open source design here. The Linux 3D/modelling application blender can be used to edit/tweak the design.
|
It turns out that in the world of track cycling one is not spoiled for choice when it comes to getting aerodynamic and deep dish carbon wheels. Front axle diameter differs from the road, and the rear axle length differs. In a pure track situation, brakes are not run so a carbon brake track is fine, but I am quite skeptical about this for durable road use: the resins used in carbon are really only good for 160-180C - which can be easily reached on a downhill; and the thermal dispersion/heat sink properties of resin are non-existent compared to any metal; this leads to deformed rims and quickly wearing down the brake track.
The only thing to do is therefore - to build your own from scratch. Get some rims with aluminium brake surfaces (front at least), get some track hubs, measure them all up, get suitable spokes, and put them all together. In the unlikely event this proves to be non-trivial, invest in a wheel truing machine and a spoke tensioning tool.
Naturally, we are not at all bereft of information technology in all of this. A collegue, Karl Stoerz, has a PHP-based website to make spoke measurements, and when it comes to tensioning them all up, there is the excellent Wheelwright desktop app which calculates overall wheel tension as you record the tension on individual spokes (see diagram below).
Mistake (i) - opting for blade spokes with an old-skool 32 hole hub; these may be great for modern radial hubs, but the cross-overs lack tension as there's less material required to bend over. This also affects the spoke tool calculations, and I ordered spokes that proved to be 4-6mm too long. So elected to go for some DT Suisse Competition round spokes (double butted 2.0/1.8/2.0mm).
Mistake (ii) - not settling for spoke tensions something of the order of my existing Mavic Open Pro rims (and same Miche Primato hubs). Rather than use the usual Newton unit for this tension/force, the bicycle industry uses a measure, Kilogram Force (Kgf), to describe this. A rim tension may be anywhere from as low as 80Kgf perhaps all the way up to 230Kgf - and a property of the materials/construction of the rim - and the limit probably known by the manufacturer. A fairly standard target tension to aim for is 110Kgf. These tension forces actually vary based upon the cross-sectional diameter of the spokes used - the wider the spoke, the more material contained within and the less deflection it'll go through to reach the required to reach the Kgf.
The Teny Bike tension meter I bought on ebay appears to be of fine build quality and consistent. It works by measuring the amount of deviation when a known spring force is applied perpendicular to the spoke. However it utilises it's own scale whereas the industry has defacto adopted the TM-1 scale as popularised by Park Tools (and their own spoke tension meters of course). Teny have (possibly helpfully) provided their own charts to map their tension/spoke deviations to Kgf.
Upon first go, I built and trued the wheel by feel, and discovered I had a Teny tension of ~4.7 which according to their translation chart above, would map to about 70Kgf - which appeared way under-tensioned. I was kinda in two minds as to how to equate the multiple-diameter DT Suisse spoke to the chart - with it rather falling somewhere between the 1.8 and 2.0 columns. With an eye to the 2.0 column I was aiming for ~5.8 Teny tension (which I though would give me ~ 110Kgf) which with brass spoke nipples was proving very difficult to tighten to.
Alas I sheared a nipple at a 6.0 Teny tension during final wheel truing. I elected to cut the spoke and relace a fresh one; but immediately upon cutting it, the rim spectacularly failed where that spoke had been. Not only that though, on closer inspection, many of the other spokes had ripple/blister/deformations on the carbon fibre as well. It's a little unclear from the radar diagram below, but the Teny tension numbers range from 5.8-6.0.
So now I'm in post-mortem mode trying to discover which/what numbers I had way too much faith in. The spokes on my Mavic rims are 2.3mm with a Teny tension of ~5.0 - which alas doesn't even register on the Teny tool chart - hardly confidence inspiring of Teny numbers. It would seem to me that a DT Suisse brass nipple is on the absolute limit of usable tension at a Teny 6.0 which probably suggests a Teny 5.0-5.25 as good working range. I think that since 3/4 of the spoke length is 1.8mm diameter, I should have translated directly off that chart - but then even at Teny 5.3 this would only have given me a 100Kgf tension. But then maybe 110Kgf is too much tension in the first place?
Since this was all rather destructive, I cross-sectioned the rim with my hacksaw and the following photo shows it's construction. There are two layers at the top with 4mm of carbon and resin and a single sidewall layer of 1.3mm; just some very tiny voids between layers at the top. The resin does look well bonded to the aluminium rim track.
Now that all of the information has been collated - off the various parties for comment and a new rim to try again ...
Ok - so we're all inner-city hipsters and upgrading our fixie to something straight off the velodrome is a life ambition right? Once you've got into your sport of choice you then want to train like and emulate the pros too - right....
I'm currently investigating some application suites to do exactly this. Wger is a hosted solution to create, record, and track all sorts of training activities, sessions, nutrition and weight. This information can then be shared with coaches and trainers.
GoldenCheetah is a cycle-specific desktop application to ingest and analyse cadence, heart-rate and powermeter information from a plethora of popular devices.
More about this soon ....
|
I think we can all generally agree that enterprise software supporting Red Hat Enterprise Linux (RHEL) is a necessary prerequisite for selling into corporate datacentres. Not only is it the predominant platform, but by paying for a RHEL subscription the customer prequalifies themselves as being prepared to pay for software - even open source software.
CentOS and Fedora as feeders to this system equally should not be ignored. While clearly a much smaller percentage of the market, this conversation also includes the SuSE Enterprise Linux/OpenSuSE ecosystems (although vendors don't seem to be specifically targeting this distro). One may certainly say, with some merit, that Ubuntu underwrites more than 50% of the public cloud; however, it's not clear that Canonical has much presence in corporate datacentres nor uptake of LTS - hence focus upon proven monetisation around RPM.
If your application/stack is in RHEL then it has great visibility in the enterprise space. This means your solution may become integral to a larger ecosystem.
Take Puppet Labs offering for example. Puppet has a lot of incumbency, and perhaps sits in the most privilegedly attainable position in this discussion. That is because Red Hat's own Release Engineering team takes responsibility for the RPM release cycle's around Puppet (the Open offering at least) across these RPM channels. Not only does this give Puppet an easy pathway to get into company's and for developers and administrators to trivially deploy it and gain expertise, but Puppet is integral to many of Red Hat's premium cloud and orchestration tools (Satellite/Puppet/Foreman/Katello). Red Hat actively promote Puppet in their sales and marketing; invite sales forces to exhibitions and events; and carry the branding on their products.
Clearly, we're not all as fortunate as Puppet Labs, but one can certainly steward their RPM packages through Red Hat's processes. Another alternative is to offer RHEL/CentOS-compatible/supported packages from your own Yum repo. This is very common and quite straightforward to implement and promote as a download/deployment option.
But here's the rub: although many company's do offer this; and even incorporate the package into an appliance (straightforward with kickstart and other imaging tools), they fail to do so properly: if you elect to isolate yourself from the distro by bundling your own Python, Ruby, Erlang, PostgreSQL, or whatever in /opt - you've really just offered a golden image/snapshot that offers none of the benefits the subscriber has paid for. Any security patches, fixes, improvements to the native distro packages aren't visible in your application.
Not only that, if there is an issue with anything outside of your specific application code - I'm much more confident Red Hat's engineering staff have much greater expertise and incentive to triage, fix, and curate Python, Ruby, Erlang, or PostgreSQL issues than you do - and almost certainly will have a much more aggressive update schedule around them. That is the reason we paid for the subscription in the first place.
Invariably these monolith RPM packages are the kitchen sink all in one deployment of a sophisticated, clustered application. This doesn't lend itself to RPM updates to the new versions (upgrading backend database schemas for example) and you're substantially locked into this VM/version until you elect to start again on the latest incantation. RPM offers a range of features for triggers, pre and post install etc which functionally can perform these tasks - but considerable engineer effort needs to be put into maintaining this to assure compatibility across versions over time - quite likely much more than the vendor is prepared to independently invest.
Whats more, the enterprise may well already have shared services and other existing infrastructure around RDBMS, message queue, web components baked into this package - but no way to integrate with these operational silos.
It is difficult to see this kind of package as anything other than trojanware. Obviously, upselling is a critical part of any offering - whether to migrate you to the vendor SAAS platform, install a licence key to access premium functionality, or other form. It's in everyone's interest to assure the financial viability of the vendor. But it is easy to see how your appliance/RPM install cannot be migrated/upgraded to the premium service simply because of the monolithic packaging - at least without manual intervention and a fundamental appreciation of version changes and persistence within the application.
Somewhat related, why not also open the SRPM that generated the RPM. Someone else just might generously package your system for other distro versions or architectures - or even improve your SPEC file - or even steward/sponsor/maintain it in a distro. Of course, if you've lazily used fpm or such tool to auto-generate your RPM, then it most probably resembles the monolith above.
It may well be another conversation entirely about how to monetise an enterprise application within Red Hat's ecosystem - and it's only one distribution channel, but very visible and probably too important not to have a narrative around.
I don't normally follow Microsoft nor it's ecosystem, but in recent months it's been brought to my notice that some really big things are afoot here. An excellent article here talks about their vNext initiatives which has a strong focus upon ensuring .NET payloads run on the Xamarin/Mono platform.
What make this very exciting is that our modern continuous integration, packaging and release management, configuration management, and monitoring now become immediately accessible for .NET payloads running in Mono. .NET developers can retain their very good desktop tools, productivity suites, and practices and we can pick up these artifacts and cloud-scale deploy them across any public/private/hybrid platform.
And the best thing is that the technology is already here and does work! We are running vanilla C# payloads on our Mono ...
BastionLinux/x86_64 uses OpenSSL 1.0.0d, with strong crypto and a bunch of elliptic curves enabled so we can support bitcoin. This version of OpenSSL is not affected by the recently published vulnerability. If you're running any of our AMI images out of AWS/Marketplace (Zenoss, Chef, Plone), then the Apache/SSL is perfectly secure.
However, this vulnerability is present in our Raspberry Pi/ARM image and if you've downloaded it we strongly recommend that you upgrade to our openssl-1.0.1g release if you've actually got your RPi internet-facing and running Apache/SSL.
Something not so well publicised is that if you are running bitcoind from Bitcoin Foundation and have exposed the RPC service to the internet (or otherwise untrusted IP's), then (i) hopefully you have set up the X509/PKI features; (ii) it is highly likely that this service is also vulnerable to Heartbleed.
Bitcoin on our image is affected and we strongly recommend that you upgrade openssl and restart your bitcoind. On BastionLinux/RPi, open the terminal and do the following commands:
$ sudo yum update $ sudo monit restart bitcoin
Whatsmore, applications such as PyQt4 which provide the basis of the bitcoin/client GUI, and BitcoinArmory also use potentially vulnerable OpenSSL on any Linux distro. I am not sure exactly how feasible it is to use this exploit to compromise an online wallet, but there is certainly plenty of incentive to make such an attempt. I would strongly advise taking your wallet offline until you've upgraded your OpenSSL.
Open source systems, tools, and practices are the future of information technology - indeed they have been for the best part of a decade. There is absolutely no need to purchase any software in order to gain familiarity or expertise in an enterprise application - simply download the leading open source equivalent from your favourite (Linux) distribution. In the unlikely event that as a major component of your application development, DBA, systems administration work day isn't utilising open source technology, you are likely to be pigeon-holing yourself into a very narrow niche.
While many things do change, some stay the same. Linux is essentially the same Unix that's been around for forty years. But with the advent of the Cloud comes a vast and distributed set of tools and systems you need to be familiar with. From GitHub to Heroku to hosted Jira, all of the services to write, deploy, and support applications are not only one-click away to procure, but free for limited-use licencing (and all built using open source software). Everything is now on-demand and hosted elsewhere. If you're thinking to buy hardware and software and spend a couple of weeks racking and setting up your environments, you've really not learnt anything from the tech wreck.
It is ubiquitous. It is in every device, from phones and consumer-grade routers all the way to enterprise storage, switches, and servers. It is unlikely that any new(ish) software application/suite will be written in a language or tool chain that is not open source - even on Microsoft operating systems. The reasons for this are manifold, but particularly that it's lowest cost, highest quality, and you're guaranteed right of use in perpetuity.
Open source is in use everywhere, however in Australia, all levels of government continue to be incredibly reticent in their adoption. This is disappointing because regardless of professional opportunities missed for local firms, as a citizen it is my taxes which are not being effectively spent on vastly more expensive and dubiously more functional software. With open solutions interdepartmental collaboration could further drive down total cost of ownership. I'd much rather these savings were materialised and used on very necessary front-line services for the general public.
We concentrate upon the more commercial aspects of Open Source and generally try to get vendors and commercial service providers to overview and then demonstrate an application or language. A wide range of vendors from Red Hat to MongoDB have presented along with an even wider range of topics from Bitcoin to Splunk.