No ads? Contribute with BitCoins: 16hQid2ddoCwHDWN9NdSnARAfdXc2Shnoa
Feb 082018
 

Some time ago, I wrote about using new (for the time) partition tables to create a memory stick with 100 partitions; each with a mountable file system on. And decided the time was right to have another look to see if things have improved … or degraded. After all, things have moved on, and everything has been updated.

I also improved the creation script slightly :-

#!/bin/zsh

disk=/dev/sdb

parted $disk mklabel gpt
for x in {1..99}     
do
  echo Partition: $x
  parted -s $disk mkpart FAT $(($x * 100)) $((x * 100 + 99))
  sleep 0.2
  mkfs -t vfat -n DOOM${x} ${disk}${x} 
  sleep 0.2
done

And I used a zsh-ism – so shoot me.

The script ran fairly well, but :-

  1. The load average shot up through the roof as copies of systemd-udevd started, worked, and closed.
  2. Strangely the links in /dev/disk/by-label (and presumably elsewhere) kept disappearing and re-appearing. As if on each partition change to the disk, all of the disk’s devices were removed and re-created. This is probably not dangerous, but harmful to performance.
  3. Given that I used sleep within my script, it is hard to criticise performance, but it did seem slow. However this is not an area worth optimising for.
  4. Unlike last time, Linux did not refuse to create any file systems.

Now onto trying to stick the memory stick of doom into various systems…

Ubuntu 17.10

This was of course the machine I ran the script on initially.

This did not go so well, with the machine initially freezing momentarily (although it is a cheap and nasty laptop), apparently silently refusing to mount half the file systems, and “Files” (or Nautilus) getting wedged at 100% processor usage.

After some 10 minutes, Nautilus was still stuck with no signs of making any progress.

After I lost patience and restarted “Files”, it came up okay showing the mounted file systems and showing the file systems it had failed to mount. On one occasion the additional file systems were shown as unmounted (and could be mounted) and on another they were shown as mounted (even though they weren’t).

So both “Files” gets a thumb down for getting stuck, and whatever else gets a thumb down for trying and failing (silently) to mount all the file systems.

This is definitely a serious degradation from the previous try, although probably GNOME-specific rather than Linux-specific. Especially as a later mounted all the file systems from the command-line on a different system without an issue.

Windows 10

Windows 10 became unusually sluggish, although it may have been in the mysterious “we’ll run Windows update at the most inconvenient time possible” mode. It did attempt to mount the file systems, and failed miserably – it mounted the first set until it ran out of drive letters.

Which is just about understandable, as there aren’t 100 drive letters. However :-

  1. Where was the message saying “There are 100 partitions in this silly USB stick. You can see the first 22; additional ones can be mounted within folders if there is important data on them.”.
  2. Why is Windows still limiting itself with single letter device names? Okay it is what we’re used to, but when you run out of drive letters, start using the file system label – “DOOM99:”. Hell, I’d like all my removable disks treated that way under Windows.

As for the whole “ran out of drive letters, so don’t bother with the rest”, how many people are aware that drives can be mounted (as Unix does) in directories?

macOS 10.13 (OSX)

Oddly enough (but perhaps sensibly), macOS refused to have anything to do with the memory stick. Indeed it popped up a dialog suggesting initialising the disk, which is perhaps not particularly sensible with a disk that could contain data.

The “Disk Utility” happily showed the disk – increasing the size of the window inconveniently wide in the process – and happily indicated 99 partitions.

At the Terminal prompt, it was apparent that the operating system had created device files for each of the partitions, but for some reason wouldn’t mount them.

Summary

Inserting a “stick of doom” with 100 partitions on it into any machine is still a risky thing to do. It’s also a dumb thing to do, but something operating system developers should be doing.

Linux (or rather GNOME) performs significant worse this time around than previously, and my suspicions are that systemd is to blame.

But however bad Linux does, none of the operating systems actually do sensible things with the “stick of doom”. macOS arguably comes closest with refusing to have anything to do with the disk, but it also encourages you to reformat the disk without saying that it could be erasing data.

Ideally, a gooey would pop up a window listing the file system labels and ask you which you want to mount. That’s not even a bad idea for a more sensibly set up memory stick.

Pebble On Steel

Nov 292017
 

If you have not already heard about it, Apple made a mindbogglingly stupid mistake with the latest release of macOS (previously known as OSX), leaving their users open to an incredibly easy exploit that would give anyone full access over an Apple in their hands. Or in some cases, remotely.

The externally visible effect of the vulnerability is that a standard Unix account (root) that was supposed to be disabled was left with a blank password. Apple uses a very common Unix security mechanism that means the root account is unnecessary as an ordinary account (i.e. nobody logs in as root), although the account has to exist so that legitimate privilege escalation works.

As an alternative, Apple uses sudo (and graphical equivalents) so that members of a certain group can run commands as root. Nothing wrong with that.

To keep things safe, Apple disabled the root account and because the account was disabled, left the password blank.

It turns out that the vulnerability was caused by a bug in Apple’s authentication system which resulted in blank passwords being reset and the account enabled. But it is more complicated than that; Apple made a number of mistakes :-

  1. The bug in the authentication system. Of course no software is bug-free, but bugs are still mistakes. Of course because no software is bug-free, it makes sense to take extra precautions to avoid bugs causing a cascade of problems.
  2. The root password should have been set to a random value to prevent access if the account was accidentally enabled.
  3. Apple’s test suite which hopefully they use to verify that new releases don’t contain previously identified bugs should also check for this vulnerability.

Although the precise details don’t matter as it’s the principle of defence in depth.

Hemisphere and Curves

Apr 232016
 

In the week, I got acquainted with the OSX Time Machine’s “Local Snapshots” which get created when your normal Time Machine volume is not available. When digging around for more information on it, I came across the trainee backup-nazi’s standard line that a backup on the same hard disk as the original data is no backup at all, and is completely useless. Well they were half-right.

To over simplify, backups perform two basic functions – they provide a copy of your data that you can use in the event of a disaster (your laptop gets stolen, your house burns down, etc.), and they allow you to recover from those “Oh! I didn’t mean to delete that file” moments. And the later use case is by far the most common – particularly in an organisation where you can ask someone else to recover a file for you.

But of course local snapshots that get created when the backup media is not available are not true backups. Any disaster that occurs is very unlikely to destroy the original data but leave the local snapshot unharmed; if it does leave it unharmed then fine. But backups are for the worst possible scenario – I did not mention your house burning down by accident.

But local snapshots are useful by themselves; whilst they are certainly not backups, they can be very useful for the most common variety of restoration job. And because they are so available, it is possible to use them for purposes we would not have thought of before.

Such as looking at what that document you are working on looked like yesterday. That paragraph you re-worked; does it really read better today than the original version yesterday? In a more technical sense, I have been using file system snapshots for years – to look back in time.

damascus-unix-prompt

Nov 072013
 

I am not aware of how widely it has been publicised, but it was certainly a surprise to me … and a few others. After upgrading to OSX 10.9 (Mavericks), and when going into the “Network Settings”, a new network device appeared. Specifically something called the “Thunderbolt Bridge”.

It turns out that this is a new feature of OSX where you can connect two Macs (or potentially other kinds of system) together with a thunderbolt cable, and run IP over that connection. Which is fast compared with normal ethernet, although it is comparable with 10GE and slower than 40GE, and 100GE (and of course slower than modern InfiniBand).

But it probably isn’t as usable as 10GE at present for the following reasons :-

  1. There’s no networking hardware support for thunderbolt networks at present.
  2. The cables are different, so offices would have to be rewired for it. Which would be very expensive.
  3. It turns out that thunderbolt takes a lot of processor power to run networking at that speed.

That’s not to say it won’t make a fine way to connect two Macs together for data transfers. With any luck (unfortunately I can’t test it), it should be a case of just plugging the two Macs together and using normal sharing mechanisms to do a transfer. Both sides should automatically configure an IP address, so normal networking services should be able to see the other Mac across the “Thunderbolt Bridge”.

The only problem with this new feature is the name – “Thunderbolt Bridge” – which might be user-friendly, but is likely to make networking people flinch. User configured network bridges have been known to cause problems!

For more details have a look here.

Oct 232013
 

Crazy experiment time. What happens when you have a disk with 100 partitions? The replacement for the old MBR standard for partitions on PC hardware is slowly being replaced with GUID partitions. The later increased the maximum number of partitions to 128 which is probably far more than anyone needs, but what happens when you have a disk with 100 partitions?

As it happens, I had a spare external drive to play with, so set something up :-

for x in {1..99}     
do
  parted /dev/sdc mkpart FAT $(($x * 100)) $((x * 100 + 99))
  mkfs -t vfat /dev/sdc${x} 
done

This took a surprising amount of time to run with two interesting effects :-

  1. The mkfs tool refused to make a filesystem on /dev/sdc16 and /dev/sdc80 as it claimed it would be creating a filesystem on a full disk device. I suspect that this is a bug due to simplistic assumption of what constitutes a full disk device based on minor device numbers (/dev/sdc16 happened to be 0 and /dev/sdc80 happened to be 64). This could probably be solved by using device nodes within /dev/disk/by-${something}/${whatever}.
  2. The Unity Launcher appeared to attempt to populate itself with the new filesystems as they were being created, but very rapidly decided not to bother. This happened several times.

Once the creation process was complete, I reconnected the external drive to my Ubuntu machine, and yes the launcher does contain a ton of hard disk icons. The launcher is still full functional, but having a hundred (or so) devices below the normal icons does make using it a little clumsy.

Fortunately it did not mount all the filesystems automatically – closing that many windows would be very tedious. Mounting them all via a file manager window was pretty tedious, but it worked :-

/dev/sdc56             95M     0   95M   0% /media/mike/8663-39C5
/dev/sdc65             95M     0   95M   0% /media/mike/8673-0919
/dev/sdc71             95M     0   95M   0% /media/mike/873E-FEE7
/dev/sdc72             95M     0   95M   0% /media/mike/8741-47B3
/dev/sdc79             95M     0   95M   0% /media/mike/874D-4B53
/dev/sdc81             95M     0   95M   0% /media/mike/874E-D280
/dev/sdc82             95M     0   95M   0% /media/mike/8752-1ACE
/dev/sdc83             95M     0   95M   0% /media/mike/8754-2562
/dev/sdc84             95M     0   95M   0% /media/mike/8755-D262
/dev/sdc86             95M     0   95M   0% /media/mike/8759-0D82
/dev/sdc87             95M     0   95M   0% /media/mike/875A-E5C5
/dev/sdc89             95M     0   95M   0% /media/mike/875E-035B
/dev/sdc92             95M     0   95M   0% /media/mike/8763-8FB5
/dev/sdc93             95M     0   95M   0% /media/mike/8765-7A2F
/dev/sdc94             95M     0   95M   0% /media/mike/8767-1DBC
/dev/sdc95             95M     0   95M   0% /media/mike/8768-D314
/dev/sdc96             95M     0   95M   0% /media/mike/876A-A46E
/dev/sdc97             95M     0   95M   0% /media/mike/876B-F064
/dev/sdc98             95M     0   95M   0% /media/mike/876D-9D90
/dev/sdc58             95M     0   95M   0% /media/mike/8666-B9AA
/dev/sdc61             94M     0   94M   0% /media/mike/866B-8EFA
/dev/sdc62             95M     0   95M   0% /media/mike/866D-1726
/dev/sdc64             95M     0   95M   0% /media/mike/8671-5EE1
/dev/sdc66             95M     0   95M   0% /media/mike/8736-C2F5
/dev/sdc67             95M     0   95M   0% /media/mike/8737-EE95
/dev/sdc68             95M     0   95M   0% /media/mike/8739-7213
/dev/sdc69             94M     0   94M   0% /media/mike/873B-181F
/dev/sdc70             95M     0   95M   0% /media/mike/873C-E80C
/dev/sdc73             95M     0   95M   0% /media/mike/8743-11E7
/dev/sdc74             95M     0   95M   0% /media/mike/8745-28A8
/dev/sdc75             95M     0   95M   0% /media/mike/8746-CA94
/dev/sdc77             95M     0   95M   0% /media/mike/874A-1D30
/dev/sdc78             95M     0   95M   0% /media/mike/874B-C1C7
/dev/sdc85             95M     0   95M   0% /media/mike/8757-77A0
/dev/sdc88             94M     0   94M   0% /media/mike/875C-6DF9
/dev/sdc90             95M     0   95M   0% /media/mike/8760-8FD5
/dev/sdc91             94M     0   94M   0% /media/mike/8762-01DA
/dev/sdc99             94M     0   94M   0% /media/mike/8770-0F74
/dev/sdc1              93M     0   93M   0% /media/mike/8609-229A
/dev/sdc17             95M     0   95M   0% /media/mike/8621-921D
/dev/sdc21             95M     0   95M   0% /media/mike/8628-8CDB
/dev/sdc22             95M     0   95M   0% /media/mike/862A-2217
/dev/sdc23             94M     0   94M   0% /media/mike/862B-8EF9
/dev/sdc25             95M     0   95M   0% /media/mike/862F-0BE5
/dev/sdc27             95M     0   95M   0% /media/mike/8633-1F9D
/dev/sdc28             95M     0   95M   0% /media/mike/8634-A26F
/dev/sdc34             95M     0   95M   0% /media/mike/863E-14EB
/dev/sdc37             95M     0   95M   0% /media/mike/8643-1F63
/dev/sdc4              95M     0   95M   0% /media/mike/860D-2753
/dev/sdc40             95M     0   95M   0% /media/mike/8647-8E49
/dev/sdc41             95M     0   95M   0% /media/mike/8649-033D
/dev/sdc42             94M     0   94M   0% /media/mike/864A-A12A
/dev/sdc43             95M     0   95M   0% /media/mike/864C-6EEF
/dev/sdc44             95M     0   95M   0% /media/mike/864E-3469
/dev/sdc45             95M     0   95M   0% /media/mike/8650-8796
/dev/sdc46             95M     0   95M   0% /media/mike/8652-64DF
/dev/sdc47             95M     0   95M   0% /media/mike/8653-F743
/dev/sdc48             95M     0   95M   0% /media/mike/8655-B14B
/dev/sdc49             95M     0   95M   0% /media/mike/8657-34FF
/dev/sdc5              95M     0   95M   0% /media/mike/860E-EBD7
/dev/sdc50             94M     0   94M   0% /media/mike/8658-A04A
/dev/sdc51             95M     0   95M   0% /media/mike/865A-D4D3
/dev/sdc52             95M     0   95M   0% /media/mike/865C-33D1
/dev/sdc53             95M     0   95M   0% /media/mike/865D-FA56
/dev/sdc54             95M     0   95M   0% /media/mike/8660-6C95
/dev/sdc55             95M     0   95M   0% /media/mike/8661-D456
/dev/sdc57             95M     0   95M   0% /media/mike/8665-0AFD
/dev/sdc59             95M     0   95M   0% /media/mike/8668-3D53
/dev/sdc6              95M     0   95M   0% /media/mike/8610-F9B0
/dev/sdc60             95M     0   95M   0% /media/mike/866A-0A0E
/dev/sdc63             95M     0   95M   0% /media/mike/866E-F6E7
/dev/sdc76             95M     0   95M   0% /media/mike/8748-8D02
/dev/sdc10             95M     0   95M   0% /media/mike/8616-B29F
/dev/sdc11             95M     0   95M   0% /media/mike/8618-6462
/dev/sdc12             94M     0   94M   0% /media/mike/861A-5208
/dev/sdc13             95M     0   95M   0% /media/mike/861B-BA6E
/dev/sdc14             95M     0   95M   0% /media/mike/861D-5133
/dev/sdc15             95M     0   95M   0% /media/mike/861E-C384
/dev/sdc18             95M     0   95M   0% /media/mike/8623-BFCF
/dev/sdc19             95M     0   95M   0% /media/mike/8625-9D85
/dev/sdc2              95M     0   95M   0% /media/mike/860A-504E
/dev/sdc20             94M     0   94M   0% /media/mike/8627-1391
/dev/sdc24             95M     0   95M   0% /media/mike/862D-457F
/dev/sdc26             95M     0   95M   0% /media/mike/8631-5F8A
/dev/sdc29             95M     0   95M   0% /media/mike/8636-2F58
/dev/sdc3              95M     0   95M   0% /media/mike/860B-8C77
/dev/sdc30             95M     0   95M   0% /media/mike/8637-F726
/dev/sdc31             94M     0   94M   0% /media/mike/8639-6B19
/dev/sdc32             95M     0   95M   0% /media/mike/863A-FBBC
/dev/sdc33             95M     0   95M   0% /media/mike/863C-AE68
/dev/sdc35             95M     0   95M   0% /media/mike/8640-3A10
/dev/sdc36             95M     0   95M   0% /media/mike/8641-93A6
/dev/sdc38             95M     0   95M   0% /media/mike/8644-AFCF
/dev/sdc39             94M     0   94M   0% /media/mike/8646-1BAE
/dev/sdc7              95M     0   95M   0% /media/mike/8612-54E8
/dev/sdc8              95M     0   95M   0% /media/mike/8613-C38C
/dev/sdc9              95M     0   95M   0% /media/mike/8615-3522

Yes I have cut the “interesting” filesystems out of that output.

Windows (7) does deal quite so well with the situation. After rebooting into Windows with the disk plugged in, the login process seemed to take longer than usual (although I don’t boot Windows enough to be sure).

Once logged in, everything seemed fine including the little popup window by the status bar saying it was configuring the plugged in disk drive. However that took longer than expected – after clicking on it for details, it took around 5 minutes to complete. At which point it stuck a red cross by the “Disk Drive” whilst it popped up an Autoplay window for drives E: through Z:. With an offer to format drive T: – so it could at least use the drive that Linux refused (by default) to format.

However except for that little red cross, there was no clear warning that it failed to do anything with nearly 80 partitions. And closing all those popup Autoplay windows was pretty tedious.

OSX (10.9) dealt a little better with the disk; it at least recognised all of the disks, and stuck up little icons for each one. And mounted them all.  However Finder didn’t seem to respond to attempts to unmount the disks … I had to resort to the command-line. Perhaps I wasn’t patient enough.

And the moral of this little crazy experiment? Whilst we can perhaps throw a little mud at Microsoft, the main lesson learnt is that you too can annoy someone using Windows by handing them an external hard disk with 100 partitions. Especially if the information they want is not in the first 20-odd partitions <Evil Grin>

Oh! And just stating the obvious – it’s a good idea to remove the partitions before putting the spare disk away, or you may encounter a nasty surprise later!

 

Aug 192011
 

Revised answer: Yes

The longer answer gets a bit more involved. First of all, there is some level of protection built into OSX against malware called File Quarantine. There are limits to how much protection this provides compared with PC anti-virus and anti-malware products as it protects against known malware at the point where the malware is installed or run.

It is also limited by the frequency at which the OSX operating system is updated – OSX is typically updated once a week – unless you put off applying updates whereas a PC-style anti-virus product will typically update it’s virus definitions on an hourly basis. This would seem to make it totally inadequate, but OSX just doesn’t have as much malware as Windows.

There are a number of possible reasons for this including that OSX is inherently more secure and that OSX just doesn’t have enough of a market share for malware authors to bother with. The truth behind the lack of malware for OSX is only known to the malware authors, although it should be noted that OSX viruses do exist (as do Linux ones).

You could take the attitude that a flood of OSX malware is due any day now, and insist on running an anti-virus product in addition to the inbuilt protection OSX has. There are of course people warning that the flood of OSX malware is just around the corner, although they tend to be people connected to the anti-virus industry so are perhaps less than totally disinterested.

Of course if you have some seriously private data to protect, you should probably consider it. But most of us don’t work for the intelligence services, so can be a little less protected … for now. This of course can all change next month, next year, or sometime, so don’t take the word of this blog entry seriously especially if the date on it is a long time ago!

Of course now some time has passed, the situation has changed (with Flashback amongst others), so the answer is that yes you do need an anti-virus product. It is true that Apple has some built-in protection against Malware, but Apple is not an AV company and so they may well react too slowly to protect you.

Jan 232011
 

During a recent upgrade of the software I have installed on my work laptop, Macports managed to get a trifle confused during the process. Firstly Enlightenment suddenly started crashing at the drop of a hat, and secondly dbus suddenly started refusing connections and claiming that X11 support was not built-in.

The first problem I solved by comping Enlightenment (E16) from scratch and overwriting the Enlightenment installed from Macports – probably not the right thing to do. It turns out that the Macport version of Enlightenment is very outdated and could do with a refresh.

The second problem was a little trickier, and may have been solved in a slightly more Macport compatible manner. In fact this problem was two problems in one. First of all, any attempt to start a GNOME-based (or presumably anything wanting to talk to dbus) would give an error indicating that X11 support was missing.

I fixed this by recompiling dbus manually :-

# port mirror dbus
#   Gets a copy of the source code used to compile the source
# cd /opt/local/var/macports/distfiles/dbus
#   Change to directory where the source code is located
# gunzip -c dbus-1.2.24.tar.gz| tar tvf -
#   Unpack the source code
# cd dbus-1.2.24
#   Enter the directory that we've just unpacked.
# ./configure --prefix=/opt/local
#   Configure the package.

If you look at the last few lines of the output from this configuration process, you will see a message of the form “Building X11 code: yes” which is what we want to see – that X11 support is being built. At this point we can build and install :-

# make
# make install

The next problem was that attempting to use the automatically launched version of dbus resulted in a “permission denied” error when trying to communicate over the socket. The work-around for this turned out to be to :-

  1. To turn off the launchd control of dbus by renaming the files /Library/LaunchAgents/org.freedesktop/dbus-session.plist and /Library/LaunchDaemons/org.freedesktop/dbus-session.plist by putting a “.” in front of their name. This stops launchd from starting anything.
  2. Changing the .xinitrc to start dbus using the syntax eval $(dbus-launch –auto-syntax) (note that I explicitly ensure that this script is launched with zsh).
Oct 232010
 

I have not had the opportunity to fiddle with one, but if Apple wants to send me one to review I am more than willing to do that! But I do have a few thoughts on the new Macbook Air. Both the 11″ one and the 13″ one. If you want something closer to a review (although nobody has had one long enough to review it properly) you can do worse than have a look at this article.

It is amusing to see the reactions to various articles published on the new Air from the “Apple is Satan” crowd, and the “Apple can do no wrong” crowd. Both as it happens are wrong.

If you look at the raw specifications of the Air – especially the 11″ model, you will see something that looks more or less like a netbook. Which of course it cannot be because Steve Jobs thinks netbooks are snake oil and useless at that. In fact it is a little bit better than that – the CPU is a little quicker, the graphics are a little better supported with a faster chipset, and there is a touch less storage (unless you go for the really expensive 256Gbyte model!).

So it’s just a very expensive netbook then ? Well, more or less. It fills roughly the same need – most people are not going to use one of these as their main machines, but will carry them around as ultra-portables. That is the kind of mobile computer you can take anywhere but once you are at your desk it sits in the drawer whilst you use a “proper computer”.

Sure the CPU is a little light-weight, but a couple of years ago a Core2Duo CPU was fine enough to get Real Work Done, so it’s still perfectly adequate to do a bit of light word processing on the train, throw up a presentation on a screen, do a little light web browsing during a boring meeting (ps: I never do this), and of course perfectly adequate for running kermit to connect to a Cisco router whilst balanced on top of a boring blue box.

Most of the compromises made in the specification are to get the size and weight of the laptop down to increase portability – that’s what a laptop is for after all! If you want power, go back to your desktop.

There is a fair amount of criticism around the cost of the Air being as it is very much more expensive than most netbooks. So ? Apple is hardly known for tackling the low end of the market where margins are small, so it is hardly surprising that things have not changed here. And of course this machine has a better specification than any netbook, whilst retaining the characteristic that Apple thinks is important in a netbook – portability.

Of course Apple is hardly perfect. Why must the battery and the SSD be fixed ? And why is there no possibility of swapping out the memory ? Whilst making these devices swappable may well make the laptop just a bit bigger and a bit heavier, it won’t be enough to ruin the portability, and will be a lot greener.

There is of course the usual criticism of Apple that their UK prices are over inflated compared to their US prices. To do a fair comparison, lets take a look :-

Cheapest Air on the US Apple Store $999
Cheapest Air on the UK Apple Store £849
US price in pounds where exchange rate is according to Wolfram Alpha £636.89
Plus UK “sales tax” (VAT) at 20% (to start in January 2011) £764.27
Penalty to UK purchasers for buying Apple £85

So why are we paying that extra £85 ?

We all know that laptop batteries fade over time to eventually give such a short running time to make the laptop unusable as a portable device. And of course circumstances change so you may suddenly need more than 64Gbytes of storage to get your work done on the move – or you just have to run a virtual machine because work has come up with the Ultimate Application that only runs under Windows, so you need a touch more memory.

Or heck, perhaps you just want to give your laptop a midlife upgrade to make it a bit quicker.

Apple want us all to throw away our old products and buy new ones – very capitalistic, but not very green.

And for all those pro-Apple and anti-Apple people out there who get so wound up by product announcements by Apple, please grow up and get a life! It’s a laptop; not a revolutionary change in the way that humanity exists.

Sep 222010
 

I have been looking into a problem with my Macbook Pro for quite a while now – despite setting the preferred sleep mode with sudo pmset -a hibernatemode 1, the laptop refuses to go into hibernate mode. It doesn’t even go into hibernate mode when the battery runs down sufficiently that it should do.

This leads to a couple of problems :-

  1. On occasions, the battery runs down enough to loose all power meaning my laptop switches off, and all running programs are terminated.
  2. Also the laptop sometimes comes out of sleep mode in my backpack getting very hot in the process.

According to a comment on a blog posting, there may be an issue with Firefox preventing hibernation from working – why that should be, I haven’t the faintest idea. Despite seeming a touch unlikely, I gave it a go – quitting Firefox and then putting the laptop to sleep.

And it hibernates!

However it turns out that stopping Firefox doesn’t prevent my main machine from hibernating. After a long hunt and several experiments, it turns out that OSX will simply not hibernate to a disk that isn’t in the slot where the hard disk is. Or in other words, you cannot hibernate when your boot disk in an SSD in the ExpressCard slot.

Which strikes me as a bit … weird. I guess the fix for this would be a proper SSD in the hard disk slot and to move the hard disk elsewhere.

After having invested in an SSD and spent far too long forcing my tired old eyes to operate in my MBP, I can confirm that hibernation does work with any kind of disk in the right slot for the hard disk.

Apr 012010
 

Apologies to those arriving here looking for information relating to U***tu and the use of this ExpressCard SSD. There is nothing relating to it here – Google has taken you on a wrong turn.

So after a false start with the wrong product I end up with a Wintec Filemate SolidGo 48GB ExpressCard 34 Ultra SSD (which is specifically a PCI-based ExpressCard rather than a USB-based one which tend to be a lot slower). The specs on this thing claim 115MB/s read and 65MB/s write which compares to my hard disk with tested scores of 80MB/s read and 78MB/s write – so a lot quicker for reads and marginally slower for writes.

How does this translate into how quickly the Macbook operates ?

Well after quickly duplicating my “OSXBOOT” partition onto the new “disk” using carbon copy cloner onto the new disk (“SSDBOOT”) I can run a few benchmarks :-

Test Result for SSD Result for Spinning Metal
Menu -> Login 31s 27s
Word startup 5s 16s
du of MacPorts 34s 109s

Well apart from the slightly surprising result of the time taken to get from the Refit menu until the login screen being actually quicker for the spinning metal disk, the SSD is approximately 3.2 times quicker! Certainly a worthwhile performance boost … and presumably a suitably chosen SATA SSD would be quicker again.

WP Facebook Auto Publish Powered By : XYZScripts.com

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close