In the not so distance past I wrote a quick review of the Haiku operating system (found here). I really liked using it and was very impressed at the work done on the operating system, but I had a terrible time trying to get the most recent nightly builds to run in VirtualBox. Well, it would install, but networking was broken in bridged mode and the SSHD network server wouldn't run. I had to use the old unofficial official release to get most of the features working.
One of the comments to that post told me the network issue had been fixed and suggested I retry the nightly build.
Well, I retried it, and the nightly build worked! I was able to use the latest VirtualBox (VirtualBox-4.3.30-101610 with the nightly build and not only did the bridged network work, but I could now ssh into the Haiku system. And there's a package of the Go language (go version 1.3-porthaiku2 haiku/386) installed through the HaikuDepot!
Despite the issue I had trying to contact the group with the contact form it appears HaikuOS is in active development. The warnings still apply that the nightly builds are not considered stable and what works one day may break the next. But I still believe the operating system is a great achievement and if you have any interest in alternative operating systems you should check it out!
Visit the project page by clicking here!
Tuesday, July 21, 2015
Sunday, July 19, 2015
Go and Mod Operations (A Performance and Testing Tale)
I was recently working on a simple application where one of the functions calculated, from a count of the Unix epoch, time remaining before an entry in slice was going to be deleted. Each entry has a timestamp, the function grabs the current time, calculates the difference, then translated it to a human readable amount of "X days, Y hours, Z minutes remaining."
It's not a hard problem to model. I had the time remaining in seconds (thanks to the epoch calculation.) I took the number of seconds in a day, an hour, and minute, then figure out how many days fit in the epoch. Then how many hours are in the remainder. Then how many minutes fit in that remainder, and seconds...well, that's the final remainder, no calculation needed.
This is an obvious use case for the mod operator. I knew that, and I did a quick search for mod support in Go; I got a hit on using Go's math package and its associated mod function. (If you're experienced with basic math operations on Go, I already know what you're thinking...just hang stick with me.)
I had remembered being advised in the past to use an int64 when dealing with epoch calculations, and that's what the application used. The library used float64, and meant I'd have to cast types to get the calculations to work. But I tried a quick implementation with the mod function from the math package, and due to rounding I would get weird results (like 2 days 24 hours and 60 minutes...)
I wanted to get this working and conceptually it was simple to implement a quick and dirty workaround.
(60 seconds a minute, 60 minutes an hour, 24 hours a day = 86,400 seconds...)
Repeat the process on the remainder each time to get hours and minutes. It's very simple to understand. I figured it was also expedient given that in my particular use case I was working with values that should never exceed 7 days.
As I was doing the initial work on this, I realized that...derp...there was a simple mod operator, %.
Yeah, forehead slap. But the documentation implied it worked with int, not int64. I thought about the situation:
A) I could go back later to fix the code...performance was acceptable at the moment.
B) The casting of values was another operation that would possibly eat a few cpu cycles.
C) I'm sure it's bad, but it can't be horribly bad to do it with some simple loops.
I implemented the looping method, tested the application, and deemed performance acceptable.
But I was still curious how horrible the looping method was compared to the %-mod. I started creating some mini-applications to test performance, and one thing led to another and soon I had combined them into one application to test various cases. The application was pieced together just for testing purposes, so it wasn't pretty, but it seemed to do the job.
In the end, I discovered my method was not only bad, but horribly bad. The fact that the application is dealing with relatively small numbers limits the performance issues, but changing implementations will probably be simple improvement.
The application takes each time entry in a slice and calculates the loops serially. My test application allowed testing serially, another that splits the slice in half for goroutines to calculate individually, a "massive" mode that threw out goroutines for each of the calculations, and finally using mod.
Additionally, in a previous test I had blogged about I discovered that the act of writing output to the terminal could, in the right circumstances, be a performance hit. To test for that, I added another flag that would silence the output.
I ran the various permutations and in summary, for every version that didn't use mod, running 500 int-sized random numbers (in a slice of int64's, to better match the conditions of the application I was testing on behalf of) through the loops took around ten and a half to eleven minutes (I used the Unix "time" utility to measure the run-time.)
Using mod (%) and casting, the time dropped to 0.016 seconds. While it didn't make a significant difference in the workaround method, using mod in silent mode dropped the time to 0.008 seconds.
Is the effect increased if the number of elements is increased? I upped it to 5,000,000 and re-ran the modulo test. In verbose mode, the time increased to 2 minutes 17 seconds. When I repeated it in silent mode, the time dropped to 0 minutes 13.753 seconds.
The takeaways?
1) When dealing with mainstream languages, the language implementors probably know better than you how to do something.
2) Test different implementations. If you suspect something may work better with another implementation, try it out.
3) Despite how horrible the workaround was, in the practical use, the numbers being calculated are small enough that the inefficient method didn't hinder the application to an unacceptable degree.
4) Once again writing strings to the terminal can significantly hinder performance, but only when the method being used for the calculation isn't horribly inefficient.
5) I really have little idea how big really big numbers are. I've read articles that point out how bad humans are at comprehending large numbers, but I tried validating random numbers generated against an online epoch time converter and they seemed correct. If someone finds where my calculations are wrong, please let me know so I can fix it.
The application performed the calculations, despite my inefficient implementation of the algorithm, with acceptable speed. I learned how poor the method was after creating a test application. And it's not hard to refactor the application in a later release.
Overall...it's a great example of how to work a little better by learning from my mistakes.
I'll end the blog post with a copy of the pieced-together test program. Some side notes; yes, it's a slice of int64, while the random call is limited to the size of int. That's to better simulate the conditions of the application I had created and to prevent weird casting causing overflows between types when doing calculations.
There's also a waitgroup (from the sync package) used to make sure main() didn't close out shortly after spawning goroutines in some of the calculation methods. Otherwise the program spawned goroutines and almost immediately existed without having a chance to write output to the terminal.
Enjoy!
It's not a hard problem to model. I had the time remaining in seconds (thanks to the epoch calculation.) I took the number of seconds in a day, an hour, and minute, then figure out how many days fit in the epoch. Then how many hours are in the remainder. Then how many minutes fit in that remainder, and seconds...well, that's the final remainder, no calculation needed.
This is an obvious use case for the mod operator. I knew that, and I did a quick search for mod support in Go; I got a hit on using Go's math package and its associated mod function. (If you're experienced with basic math operations on Go, I already know what you're thinking...just hang stick with me.)
I had remembered being advised in the past to use an int64 when dealing with epoch calculations, and that's what the application used. The library used float64, and meant I'd have to cast types to get the calculations to work. But I tried a quick implementation with the mod function from the math package, and due to rounding I would get weird results (like 2 days 24 hours and 60 minutes...)
I wanted to get this working and conceptually it was simple to implement a quick and dirty workaround.
// How many days? for int64Difference >= 86400 { intDays++ int64Difference = int64Difference - 86400 }
(60 seconds a minute, 60 minutes an hour, 24 hours a day = 86,400 seconds...)
Repeat the process on the remainder each time to get hours and minutes. It's very simple to understand. I figured it was also expedient given that in my particular use case I was working with values that should never exceed 7 days.
As I was doing the initial work on this, I realized that...derp...there was a simple mod operator, %.
Yeah, forehead slap. But the documentation implied it worked with int, not int64. I thought about the situation:
A) I could go back later to fix the code...performance was acceptable at the moment.
B) The casting of values was another operation that would possibly eat a few cpu cycles.
C) I'm sure it's bad, but it can't be horribly bad to do it with some simple loops.
I implemented the looping method, tested the application, and deemed performance acceptable.
But I was still curious how horrible the looping method was compared to the %-mod. I started creating some mini-applications to test performance, and one thing led to another and soon I had combined them into one application to test various cases. The application was pieced together just for testing purposes, so it wasn't pretty, but it seemed to do the job.
In the end, I discovered my method was not only bad, but horribly bad. The fact that the application is dealing with relatively small numbers limits the performance issues, but changing implementations will probably be simple improvement.
The application takes each time entry in a slice and calculates the loops serially. My test application allowed testing serially, another that splits the slice in half for goroutines to calculate individually, a "massive" mode that threw out goroutines for each of the calculations, and finally using mod.
Additionally, in a previous test I had blogged about I discovered that the act of writing output to the terminal could, in the right circumstances, be a performance hit. To test for that, I added another flag that would silence the output.
I ran the various permutations and in summary, for every version that didn't use mod, running 500 int-sized random numbers (in a slice of int64's, to better match the conditions of the application I was testing on behalf of) through the loops took around ten and a half to eleven minutes (I used the Unix "time" utility to measure the run-time.)
Using mod (%) and casting, the time dropped to 0.016 seconds. While it didn't make a significant difference in the workaround method, using mod in silent mode dropped the time to 0.008 seconds.
Is the effect increased if the number of elements is increased? I upped it to 5,000,000 and re-ran the modulo test. In verbose mode, the time increased to 2 minutes 17 seconds. When I repeated it in silent mode, the time dropped to 0 minutes 13.753 seconds.
The takeaways?
1) When dealing with mainstream languages, the language implementors probably know better than you how to do something.
2) Test different implementations. If you suspect something may work better with another implementation, try it out.
3) Despite how horrible the workaround was, in the practical use, the numbers being calculated are small enough that the inefficient method didn't hinder the application to an unacceptable degree.
4) Once again writing strings to the terminal can significantly hinder performance, but only when the method being used for the calculation isn't horribly inefficient.
5) I really have little idea how big really big numbers are. I've read articles that point out how bad humans are at comprehending large numbers, but I tried validating random numbers generated against an online epoch time converter and they seemed correct. If someone finds where my calculations are wrong, please let me know so I can fix it.
The application performed the calculations, despite my inefficient implementation of the algorithm, with acceptable speed. I learned how poor the method was after creating a test application. And it's not hard to refactor the application in a later release.
Overall...it's a great example of how to work a little better by learning from my mistakes.
I'll end the blog post with a copy of the pieced-together test program. Some side notes; yes, it's a slice of int64, while the random call is limited to the size of int. That's to better simulate the conditions of the application I had created and to prevent weird casting causing overflows between types when doing calculations.
There's also a waitgroup (from the sync package) used to make sure main() didn't close out shortly after spawning goroutines in some of the calculation methods. Otherwise the program spawned goroutines and almost immediately existed without having a chance to write output to the terminal.
Enjoy!
package main import ( "fmt" "math/rand" "os" "strconv" "sync" "time" ) var slcTimes []int64 var boolSilent bool func main() { var intCounter int var strCounter string var strMode string var strChatty string if len(os.Args) < 4 { fmt.Println("Usage: ./loopcheck <count> <serial|parallel|modulo|massive> <verbose|silent>") os.Exit(1) } strCounter = os.Args[1] strMode = os.Args[2] strChatty = os.Args[3] intCounter, err := strconv.Atoi(strCounter) if err != nil { fmt.Println("This doesn't appear to be a valid count: " + strCounter) os.Exit(1) } if strMode != "serial" && strMode != "parallel" && strMode != "massive" && strMode != "modulo" { fmt.Println("Need a mode as second argument of serial, parallel, massive or modulo, not " + strMode) os.Exit(1) } switch strChatty { case "verbose": boolSilent = true case "silent": boolSilent = false default: fmt.Println("Please set verbose or silent run") os.Exit(1) } // Seed the Random function rand.Seed(time.Now().UTC().UnixNano()) var int64Random int64 // 604,800 seconds is a week... // Fill the slice with values for b := 0; b < intCounter; b++ { //int64Random = rand.Int63() int64Random = int64(rand.Int()) slcTimes = append(slcTimes, int64Random) } if strMode == "serial" { for i := range slcTimes { HowMuchTime(i) } } if strMode == "massive" { var wg sync.WaitGroup wg.Add(len(slcTimes)) for i := range slcTimes { go HowMuchTimeMassive(&wg, i) } wg.Wait() } if strMode == "modulo" { for i := range slcTimes { // Set the integers intCenturies := 0 intDecades := 0 intYears := 0 intMonths := 0 intWeeks := 0 intDays := 0 intHours := 0 intMinutes := 0 // Let's get the time to deletion for each entry int64TimeInSeconds := slcTimes[i] // How many centuries? intCenturies = int(int64TimeInSeconds / 3155692600) int64TimeInSeconds = int64TimeInSeconds % 3155692600 // How many decades? intDecades = int(int64TimeInSeconds / 315569260) int64TimeInSeconds = int64TimeInSeconds % 315569260 // How many years? intYears = int(int64TimeInSeconds / 31556926) int64TimeInSeconds = int64TimeInSeconds % 31556926 // How many months? intMonths = int(int64TimeInSeconds / 2629743) int64TimeInSeconds = int64TimeInSeconds % 2629743 // How many weeks? intWeeks = int(int64TimeInSeconds / 604800) int64TimeInSeconds = int64TimeInSeconds % 604800 // How many days? intDays = int(int64TimeInSeconds / 86400) int64TimeInSeconds = int64TimeInSeconds % 86400 // How many hours? intHours = int(int64TimeInSeconds / 3600) int64TimeInSeconds = int64TimeInSeconds % 3600 // How many minutes? intMinutes = int(int64TimeInSeconds / 60) // Convert to strings strCenturies := strconv.Itoa(intCenturies) strDecades := strconv.Itoa(intDecades) strYears := strconv.Itoa(intYears) strMonths := strconv.Itoa(intMonths) strWeeks := strconv.Itoa(intWeeks) strDays := strconv.Itoa(intDays) strHours := strconv.Itoa(intHours) strMinutes := strconv.Itoa(intMinutes) // Formatting strCenturies = strCenturies + " Centuries " strDecades = strDecades + " Decades " strYears = strYears + " Years " strMonths = strMonths + " Months " strWeeks = strWeeks + " Weeks " strDays = strDays + " Days " strHours = strHours + " Hours " strMinutes = strMinutes + " Minutes " strMessages := "From " + strconv.FormatInt(slcTimes[i], 10) + " : " + strCenturies + strDecades + strYears + strMonths + strWeeks + strDays + strHours + strMinutes if boolSilent != false { fmt.Println("Iteration " + strconv.Itoa(i+1) + " : " + strMessages) } } } if strMode == "parallel" { var intMax int = intCounter - 1 var intTemp int var wg sync.WaitGroup wg.Add(2) intTemp = intCounter / 2 go HowMuchTimeParallel(&wg, 0, intTemp) go HowMuchTimeParallel(&wg, intTemp+1, intMax) wg.Wait() } } func HowMuchTime(i int) { var intCenturies int var intDecades int var intYears int var intMonths int var intWeeks int var intDays int var intHours int var intMinutes int var strMessages string // Set the integers intCenturies = 0 intDecades = 0 intYears = 0 intMonths = 0 intWeeks = 0 intDays = 0 intHours = 0 intMinutes = 0 // Let's get the time to deletion for each entry int64TimeInSeconds := slcTimes[i] // How many centuries? for int64TimeInSeconds >= 3155692600 { intCenturies++ int64TimeInSeconds = int64TimeInSeconds - 3155692600 } // How many decades? for int64TimeInSeconds >= 315569260 { intDecades++ int64TimeInSeconds = int64TimeInSeconds - 315569260 } // How many years? for int64TimeInSeconds >= 31556926 { intYears++ int64TimeInSeconds = int64TimeInSeconds - 31556926 } // How many months? for int64TimeInSeconds >= 2629743 { intMonths++ int64TimeInSeconds = int64TimeInSeconds - 2629743 } // How many weeks? for int64TimeInSeconds >= 604800 { intWeeks++ int64TimeInSeconds = int64TimeInSeconds - 604800 } // How many days? for int64TimeInSeconds >= 86400 { intDays++ int64TimeInSeconds = int64TimeInSeconds - 86400 } // How many hours? for int64TimeInSeconds >= 3600 { intHours++ int64TimeInSeconds = int64TimeInSeconds - 3600 } // How many minutes? for int64TimeInSeconds >= 60 { intMinutes++ int64TimeInSeconds = int64TimeInSeconds - 60 } // Convert to strings strCenturies := strconv.Itoa(intCenturies) strDecades := strconv.Itoa(intDecades) strYears := strconv.Itoa(intYears) strMonths := strconv.Itoa(intMonths) strWeeks := strconv.Itoa(intWeeks) strDays := strconv.Itoa(intDays) strHours := strconv.Itoa(intHours) strMinutes := strconv.Itoa(intMinutes) // Formatting strCenturies = strCenturies + " Centuries " strDecades = strDecades + " Decades " strYears = strYears + " Years " strMonths = strMonths + " Months " strWeeks = strWeeks + " Weeks " strDays = strDays + " Days " strHours = strHours + " Hours " strMinutes = strMinutes + " Minutes " strMessages = "From " + strconv.FormatInt(slcTimes[i], 10) + " : " + strCenturies + strDecades + strYears + strMonths + strWeeks + strDays + strHours + strMinutes if boolSilent != false { fmt.Println("Iteration " + strconv.Itoa(i+1) + " : " + strMessages) } } func HowMuchTimeMassive(wg *sync.WaitGroup, i int) { var intCenturies int var intDecades int var intYears int var intMonths int var intWeeks int var intDays int var intHours int var intMinutes int var strMessages string // Set the integers intCenturies = 0 intDecades = 0 intYears = 0 intMonths = 0 intWeeks = 0 intDays = 0 intHours = 0 intMinutes = 0 // Let's get the time to deletion for each entry int64TimeInSeconds := slcTimes[i] // How many centuries? for int64TimeInSeconds >= 3155692600 { intCenturies++ int64TimeInSeconds = int64TimeInSeconds - 3155692600 } // How many decades? for int64TimeInSeconds >= 315569260 { intDecades++ int64TimeInSeconds = int64TimeInSeconds - 315569260 } // How many years? for int64TimeInSeconds >= 31556926 { intYears++ int64TimeInSeconds = int64TimeInSeconds - 31556926 } // How many months? for int64TimeInSeconds >= 2629743 { intMonths++ int64TimeInSeconds = int64TimeInSeconds - 2629743 } // How many weeks? for int64TimeInSeconds >= 604800 { intWeeks++ int64TimeInSeconds = int64TimeInSeconds - 604800 } // How many days? for int64TimeInSeconds >= 86400 { intDays++ int64TimeInSeconds = int64TimeInSeconds - 86400 } // How many hours? for int64TimeInSeconds >= 3600 { intHours++ int64TimeInSeconds = int64TimeInSeconds - 3600 } // How many minutes? for int64TimeInSeconds >= 60 { intMinutes++ int64TimeInSeconds = int64TimeInSeconds - 60 } // Convert to strings strCenturies := strconv.Itoa(intCenturies) strDecades := strconv.Itoa(intDecades) strYears := strconv.Itoa(intYears) strMonths := strconv.Itoa(intMonths) strWeeks := strconv.Itoa(intWeeks) strDays := strconv.Itoa(intDays) strHours := strconv.Itoa(intHours) strMinutes := strconv.Itoa(intMinutes) // Formatting strCenturies = strCenturies + " Centuries " strDecades = strDecades + " Decades " strYears = strYears + " Years " strMonths = strMonths + " Months " strWeeks = strWeeks + " Weeks " strDays = strDays + " Days " strHours = strHours + " Hours " strMinutes = strMinutes + " Minutes " strMessages = "From " + strconv.FormatInt(slcTimes[i], 10) + " : " + strCenturies + strDecades + strYears + strMonths + strWeeks + strDays + strHours + strMinutes if boolSilent != false { fmt.Println("Iteration " + strconv.Itoa(i+1) + " : " + strMessages) } wg.Done() } func HowMuchTimeParallel(wg *sync.WaitGroup, min int, max int) { var intCenturies int var intDecades int var intYears int var intMonths int var intWeeks int var intDays int var intHours int var intMinutes int var strMessages string // Set the integers intCenturies = 0 intDecades = 0 intYears = 0 intMonths = 0 intWeeks = 0 intDays = 0 intHours = 0 intMinutes = 0 for i := min; i <= max; i++ { // Let's get the time to deletion for each entry int64TimeInSeconds := slcTimes[i] // How many centuries? for int64TimeInSeconds >= 3155692600 { intCenturies++ int64TimeInSeconds = int64TimeInSeconds - 3155692600 } // How many decades? for int64TimeInSeconds >= 315569260 { intDecades++ int64TimeInSeconds = int64TimeInSeconds - 315569260 } // How many years? for int64TimeInSeconds >= 31556926 { intYears++ int64TimeInSeconds = int64TimeInSeconds - 31556926 } // How many months? for int64TimeInSeconds >= 2629743 { intMonths++ int64TimeInSeconds = int64TimeInSeconds - 2629743 } // How many weeks? for int64TimeInSeconds >= 604800 { intWeeks++ int64TimeInSeconds = int64TimeInSeconds - 604800 } // How many days? for int64TimeInSeconds >= 86400 { intDays++ int64TimeInSeconds = int64TimeInSeconds - 86400 } // How many hours? for int64TimeInSeconds >= 3600 { intHours++ int64TimeInSeconds = int64TimeInSeconds - 3600 } // How many minutes? for int64TimeInSeconds >= 60 { intMinutes++ int64TimeInSeconds = int64TimeInSeconds - 60 } // Convert to strings strCenturies := strconv.Itoa(intCenturies) strDecades := strconv.Itoa(intDecades) strYears := strconv.Itoa(intYears) strMonths := strconv.Itoa(intMonths) strWeeks := strconv.Itoa(intWeeks) strDays := strconv.Itoa(intDays) strHours := strconv.Itoa(intHours) strMinutes := strconv.Itoa(intMinutes) // Formatting strCenturies = strCenturies + " Centuries " strDecades = strDecades + " Decades " strYears = strYears + " Years " strMonths = strMonths + " Months " strWeeks = strWeeks + " Weeks " strDays = strDays + " Days " strHours = strHours + " Hours " strMinutes = strMinutes + " Minutes " strMessages = " From " + strconv.FormatInt(slcTimes[i], 10) + " : " + strCenturies + strDecades + strYears + strMonths + strWeeks + strDays + strHours + strMinutes if boolSilent != false { fmt.Println("Iteration " + strconv.Itoa(i+1) + " : " + strMessages) } } wg.Done() }
Wednesday, July 8, 2015
Windows 8.1 and BootCamp: I Hate It
I normally use a Mac to get things done. Of course there are times that require I use Windows (unless there's a Mac release of Active Directory management tools...), and when that happens I use Windows 7 running in VirtualBox.
Why?
Because I hate Windows 8.
Every time I've used it, I'm reminded of more reasons why I don't like it. And I've talked to many other people who have expressed the same first impression I had: the user interface was created only for tablets with touch screens. That is by far the most common opinion I run into. "If this were on a tablet, I'd probably like it more," they lament.
My son has a Mac. I said if he wanted a computer, he was either going to get a Mac or he'd have to learn how to support his own technology. For his purposes...which he swore was mostly Minecraft with a heavy does of watching YouTube videos...a Mac was perfectly fine.
Fast forward a bit; somewhere he was exposed to videos of Steam. He wanted to play some kind of video games that were only supported on Windows. Windows! "Please? Please? PLEAASE!?," he begged.
"If you want it, you have to buy it."
So he bought Windows. A boxed 8.1 DVD set. Ugh.
I eventually agreed as a birthday gift to install Windows using BootCamp on his MacBook Pro. If you're not familiar with BootCamp, it is a concession made by Apple for people who for some reason or another require not only Windows on their Mac, but direct access to the hardware. Usually it's because of a shortcoming in virtualization; some driver pukes or a piece of hardware's interface isn't perfectly emulated. Once in awhile it's because someone finds the small performance hit from virtualization to be unacceptable. For these occasions Apple released a suite of drivers and a configuration utility to assist in repartitioning your hard drive and installing a dedicated full installation of Windows on the Mac.
I have never been a fan of BootCamp. Part of the reason the Mac is great is because of OS X being tightly integrated with the hardware. Apple doesn't toss the operating system on as an afterthought. Windows more or less cripples a machine that was designed to work with OS X, and Apple has no reason to go out of their way to make the experience better.
But I agreed to try getting that overpriced Windows DVD to install on his Mac. I installed a 500GB hybrid drive...his existing drive was too small to adequately handle the installation. I used the BootCamp Assistant utility, included with OS X, to divide the drive into two partitions. BootCamp Assistant then took the ISO image I created from the 64 bit disc and applied the installation to an external USB drive, then tried to download support software. I had a slow connection so I let it run while I went to bed.
Woke up in the morning and tried the reboot. It wouldn't work. I mean, Windows 8.1 setup came up, but there was no keyboard or mouse. It was stuck at the setup screen.
Reboot. I held the command-R keys to get to recovery mode, and from there told it to boot to OS X. "Maybe the installation was corrupt, maybe I should try that again."
I re-ran the BootCamp Assistant and re-created the install. It complained because a partition already existed for Windows, but then dutifully reformatted the external drive for the installation process and tried downloading BootCamp drivers. After sitting for several minutes, it puked an error hinting that for some reason known only to robots and silicon gods it couldn't download the utilities.
This happened a few times. I'd reattempt the installation process, only to have it throw an error at me.
Eventually I gave up and told it only to create the install disk. I'd worry about the install of BootCamp utilities later.
Reboot...nothing. It just wasn't able to run the installer properly. What the hell? Bad ISO image? Not supporting the USB drive because it wasn't fast enough or recognized properly at boot?
I put in the Windows DVD and tried the install. Booting from the DVD worked; I had my keyboard and mouse working and it prompted for the 25 character key. Finally...installed the operating system. Only...no BootCamp utility. And no drivers. Including the network driver, so I couldn't get the laptop to a point where it could download drivers and troubleshoot on its own. Worse, it didn't have the utility for booting to OS X from the system tray.
I ended up telling it to reboot and using the recovery boot option to choose OS X as the startup disk. Yes, the Option key is supposed to give you a menu to choose your startup disk...somehow that key is not working on his laptop.
I poked around and discovered a that you can download the BootCamp utilities bundle from Apple. It was nearly a gig in size; I let it trickle in over a couple of hours. Once that had completed I saved it to a USB drive and rebooted to Windows.
Only Windows refused to recognize the drive. Windows could tell the USB drive was plugged in, but wouldn't recognize it as being properly formatted with a filesystem, no matter what filesystem was formatted on the drive.
I rebooted back to OS X and found a spare burnable DVD. I burned a disk of the unzipped drivers and setup program and rebooted back to Windows; huzzah! It sees the utilities!
Then Windows puked an error. The app could not be run.
I did a quick search and discovered the specific version of the download I used may not be able to work on that model Mac. There was a slightly lower version that was supposed to work, though. Another gig download.
At this point I was no longer at home; we were on vacation, and I didn't have access to another disc on which to burn the drivers. I'd have to find another way to get the downloaded files to a spot Windows could see the files.
While the second version of the support files installer completed I started transferring two other files down; one, Parallels, a virtualization application that could run the BootCamped Windows installation in a VM and should also easily see the local OS X filesystem as a shared folder. The other was an NTFS driver from Paragon software.
Another clarification; OS X can see the Windows partition. The problem is that it will mount the drive read-only. By default...without playing with some flags and command-line magic...OS X cannot write to the partition. The Paragon driver was theoretically less involved to try; it has a trial period that would let me transfer the file in question to the Windows partition.
Installed driver, reboot again to OS X, and copied the file over. No errors! YES! Now to reboot to...where's Windows?
Yeah, for reasons I'm not entirely sure of the Windows startup drive disappeared as an option from the startup disk list. sigh
I uninstalled the Paragon software and the Windows drive reappeared as a startup disk option. YAY!
Reboot. Unzipped the new BootCamp utilities. Ran setup. "Do you want to let <setup.exe> make changes to your system?"
YES DAMMIT.
"Sorry, this app cannot run."
DAMMIT!
Wait...what if...
Yeah. I gave a full Fullerton sigh when I realized that at some point in my swapping things around and trying to get Windows to install properly the 64 bit and 32 bit DVD's were swapped. BootCamp was for 64 bit Windows and the 32 bit version was currently installed. No no no no no...
I rebooted again and wrangled the 64 bit DVD to install. Once more...I think at this point I'd entered the 25 digit code three or four times at this point...I entered that damned code and managed to reach the custom install selection. I highlighted the partition and told it to format it to a clean slate.
"I can't install there. The partition type is not GPT."
The fuck?
Fine. Delete the partition, Windows. Recreate and format it.
"I can't install there. It's not GPT!"
Flabbergasted that Windows isn't apparently smart enough to create the proper partition itself, I rebooted to OS X and opened Disk Utility. From there I deleted that partition and recreated it, which confirmed it was created by default as a GPT partition...something else must have altered it during the installation process. I formatted it as FAT for good measure.
Time to iterate through my install checklist again. Rebooted with the DVD. Made sure it was 64 bit. Re-enter that damned key again. Custom install. Highlight the partition. "I can't install there. It's not NTFS!"
"Format it, dumbass."
"Okay!"
This time, no error. It installed.
Booted, finished "configuring hardware." Told me in big cartoony letters how wonderful Windows was going to be. Let me configure a user account. No hardware was working beyond the keyboard, mouse and display.
Okay, so it was the non-64 bitness keeping the setup for BootCamp utilities working...let's stick in the disc I had made. This time the original "not gonna do it" error didn't appear; it gave me a different error, that it wasn't meant for my model Mac! In this case it was a better error, though, because now it was the installer giving me a specific error and not Windows puking a generically unhelpful error.
Reboot to recovery boot. Change startup disk to OS X. Reboot.
Reinstall Paragon driver. Reboot. Copy the older version of BootCamp utilities over to Windows. Uninstall Paragon. Select Windows as the startup disk. Reboot.
Unzip the utilities in Windows. Run setup.
It worked.
Holy shit. It worked. It's been two days of downloading and reconfiguring and troubleshooting...and now it was working. No more warning symbols on the network hardware. Webcam worked. Bluetooth. Updated USB. It was all working!
This wasn't even a case of being irritated with the interface as I normally experienced...I'd managed to remember that I had to scroll the pointer along the right side to actually find a menu item I wanted, or to even find the damned shutdown menu. I was accidentally running into the fact that Windows 8 has a cartoony, dumbed down interface to tell me something that also was available from an actual, more familiar control panel version when I accidentally took a wrong turn in the access methods (example: there's a Windows Update that gives you some kind of text wall status, and another that uses the Windows Update control panel...not that either one gives real-time updates on status.) At this point I didn't even have the energy to complain about the unhelpfully generic error messages (YOU KNEW THE PROBLEM WAS RELATED TO A 64 BIT DRIVER ON A 32 BIT OS, YOU BASTARD.)
Some people would blame Apple. I can't. Not just out of fanboyism, but because I really suspect that as far as they're concerned, if you want to run Windows you should have a PC. There's a reason I said BootCamp was a concession...after following Apple news stories for years, reading about Steve Jobs, and paying attention to the details Apple puts into their products, I honestly think they find the notion of Windows on their hardware a distasteful pile of wretchedness they tolerate only to keep gamers from using it as an excuse to refuse trying Apple products. The drivers seem almost half-hearted; they usually work, but tend to lag behind Windows releases when updates are needed. And they aren't necessarily great; for example, failing to support dual-Thunderbolt displays. Windows will see one, but leave the other blank. Why? Apple doesn't seem to care to address it.
And frankly I can see why. The OS is coupled to the hardware. Apple tossed basic support over the fence and shrugged before walking away.
I can't blame Microsoft for the lack of Apple support. It would be nice if they saw more of that hardware by default, but...meh. Apple comes with OS X. Microsoft shouldn't necessarily have to support a system that isn't really meant to run their product.
Nope. The experiences I had getting BootCamp to run is pretty much the kind of pain I expect in trying to shoehorn an operating system Apple doesn't like onto a hardware configuration Microsoft doesn't want to support. Part of me expects this setup to break in the near future...just one update away from another pain point.
What I can say:
I initially told my son he would have to install BootCamp. He should learn how to use his system properly, and if he really wanted this he should do it. And I made no secret that I was disappointed when he didn't make much effort to do this, opting instead to beg until his birthday for us to do this for him. At the time I didn't expect it to be this much of a hassle, though...there's absolutely no way he could have figured this out on his own without a week of study and probably a lot of back and forth on the apple.stackexchange.com site, learning about partitions, formatting, and how drivers interact on systems. A non-problematic install would have been one thing, but something was definitely broken on his system's ability to properly boot from the USB drive, and something with the Apple download site wasn't cooperating half the time with our slow connection to get the proper utilities in the first place.
Windows 8x sucks at giving proper error messages. C'mon...how hard is it to know the error was running a 64 bit installer on a 32 bit operating system?
I'm pretty sure Apple could have created a read/write NTFS driver. In fact, the ability is in OS X...just shut off by default. You can follow some semi-documented procedure to enable it and mount an NTFS volume if you're willing to risk it...I'm just afraid of what risks they're not talking about.
Microsoft is supposedly making it easier...free, even...to get Windows 10. I pray to $DEITY that means they're getting rid of that goddamned 25-character key. I must have entered it five or six times over the course of this ordeal, and every time it was installed before starting a process that would end in NOPE NOT GONNA DO IT HAHA!
Oh, and after getting the key entered the final time and getting drivers working and getting online...Windows still needed activation, so if I didn't get the network driver working...which in one iteration I had this situation...Windows was warning me that I had to call Microsoft to activate it before certain things would work properly. I was even more pissed at the fact this was a purchased, non-pirated, store-box DVD edition of Windows having me enter...and enter...and enter...that 25 character code and it still had another hoop to jump. OS X? It'll reinstall over the Internet by booting to recovery mode. No questions. Just a few clicks. Screw Windows.
If BootCamp fails and you need to reinstall, you may have to delete the partition from Disk Utility. Recreate it from Disk Utility. I reformatted it as a FAT partition so it would be visible from within Windows' setup...if it's using a GUID partition table, Windows should be willing to see and format it.
If you're installing BootCamp utilities separately, make sure you get the correct version for your Mac hardware. Unlike most of the OS X operating system and drivers, BootCamp is finicky.
I suspect Parallels would have worked to bridge my software-transfer problem. Paragon worked in this case, so far without cruft being visible after the uninstaller was run. Trying to get pain-in-the-ass software like this is great for reminding you that you can get creative to solve problems. The stress probably does shorten your life a little, too, though.
Last thing...don't run BootCamp unless you really, really need to. Parallels is a fantastic product. VirtualBox works well most of the time and for most purposes. BootCamp forces you to get meh driver support and sacrifice a fixed portion of your hard drive. If you're going to use it, have a really good reason to do so.
Now if you'll excuse me, I'm going to see if I have some more Bacardi in the kitchen. This installation of Windows has left me with an extraordinary amount of stress to burn off...
Why?
Because I hate Windows 8.
Every time I've used it, I'm reminded of more reasons why I don't like it. And I've talked to many other people who have expressed the same first impression I had: the user interface was created only for tablets with touch screens. That is by far the most common opinion I run into. "If this were on a tablet, I'd probably like it more," they lament.
My son has a Mac. I said if he wanted a computer, he was either going to get a Mac or he'd have to learn how to support his own technology. For his purposes...which he swore was mostly Minecraft with a heavy does of watching YouTube videos...a Mac was perfectly fine.
Fast forward a bit; somewhere he was exposed to videos of Steam. He wanted to play some kind of video games that were only supported on Windows. Windows! "Please? Please? PLEAASE!?," he begged.
"If you want it, you have to buy it."
So he bought Windows. A boxed 8.1 DVD set. Ugh.
I eventually agreed as a birthday gift to install Windows using BootCamp on his MacBook Pro. If you're not familiar with BootCamp, it is a concession made by Apple for people who for some reason or another require not only Windows on their Mac, but direct access to the hardware. Usually it's because of a shortcoming in virtualization; some driver pukes or a piece of hardware's interface isn't perfectly emulated. Once in awhile it's because someone finds the small performance hit from virtualization to be unacceptable. For these occasions Apple released a suite of drivers and a configuration utility to assist in repartitioning your hard drive and installing a dedicated full installation of Windows on the Mac.
I have never been a fan of BootCamp. Part of the reason the Mac is great is because of OS X being tightly integrated with the hardware. Apple doesn't toss the operating system on as an afterthought. Windows more or less cripples a machine that was designed to work with OS X, and Apple has no reason to go out of their way to make the experience better.
But I agreed to try getting that overpriced Windows DVD to install on his Mac. I installed a 500GB hybrid drive...his existing drive was too small to adequately handle the installation. I used the BootCamp Assistant utility, included with OS X, to divide the drive into two partitions. BootCamp Assistant then took the ISO image I created from the 64 bit disc and applied the installation to an external USB drive, then tried to download support software. I had a slow connection so I let it run while I went to bed.
Woke up in the morning and tried the reboot. It wouldn't work. I mean, Windows 8.1 setup came up, but there was no keyboard or mouse. It was stuck at the setup screen.
Reboot. I held the command-R keys to get to recovery mode, and from there told it to boot to OS X. "Maybe the installation was corrupt, maybe I should try that again."
I re-ran the BootCamp Assistant and re-created the install. It complained because a partition already existed for Windows, but then dutifully reformatted the external drive for the installation process and tried downloading BootCamp drivers. After sitting for several minutes, it puked an error hinting that for some reason known only to robots and silicon gods it couldn't download the utilities.
This happened a few times. I'd reattempt the installation process, only to have it throw an error at me.
Eventually I gave up and told it only to create the install disk. I'd worry about the install of BootCamp utilities later.
Reboot...nothing. It just wasn't able to run the installer properly. What the hell? Bad ISO image? Not supporting the USB drive because it wasn't fast enough or recognized properly at boot?
I put in the Windows DVD and tried the install. Booting from the DVD worked; I had my keyboard and mouse working and it prompted for the 25 character key. Finally...installed the operating system. Only...no BootCamp utility. And no drivers. Including the network driver, so I couldn't get the laptop to a point where it could download drivers and troubleshoot on its own. Worse, it didn't have the utility for booting to OS X from the system tray.
I ended up telling it to reboot and using the recovery boot option to choose OS X as the startup disk. Yes, the Option key is supposed to give you a menu to choose your startup disk...somehow that key is not working on his laptop.
I poked around and discovered a that you can download the BootCamp utilities bundle from Apple. It was nearly a gig in size; I let it trickle in over a couple of hours. Once that had completed I saved it to a USB drive and rebooted to Windows.
Only Windows refused to recognize the drive. Windows could tell the USB drive was plugged in, but wouldn't recognize it as being properly formatted with a filesystem, no matter what filesystem was formatted on the drive.
I rebooted back to OS X and found a spare burnable DVD. I burned a disk of the unzipped drivers and setup program and rebooted back to Windows; huzzah! It sees the utilities!
Then Windows puked an error. The app could not be run.
I did a quick search and discovered the specific version of the download I used may not be able to work on that model Mac. There was a slightly lower version that was supposed to work, though. Another gig download.
At this point I was no longer at home; we were on vacation, and I didn't have access to another disc on which to burn the drivers. I'd have to find another way to get the downloaded files to a spot Windows could see the files.
While the second version of the support files installer completed I started transferring two other files down; one, Parallels, a virtualization application that could run the BootCamped Windows installation in a VM and should also easily see the local OS X filesystem as a shared folder. The other was an NTFS driver from Paragon software.
Another clarification; OS X can see the Windows partition. The problem is that it will mount the drive read-only. By default...without playing with some flags and command-line magic...OS X cannot write to the partition. The Paragon driver was theoretically less involved to try; it has a trial period that would let me transfer the file in question to the Windows partition.
Installed driver, reboot again to OS X, and copied the file over. No errors! YES! Now to reboot to...where's Windows?
Yeah, for reasons I'm not entirely sure of the Windows startup drive disappeared as an option from the startup disk list. sigh
I uninstalled the Paragon software and the Windows drive reappeared as a startup disk option. YAY!
Reboot. Unzipped the new BootCamp utilities. Ran setup. "Do you want to let <setup.exe> make changes to your system?"
YES DAMMIT.
"Sorry, this app cannot run."
DAMMIT!
Wait...what if...
Yeah. I gave a full Fullerton sigh when I realized that at some point in my swapping things around and trying to get Windows to install properly the 64 bit and 32 bit DVD's were swapped. BootCamp was for 64 bit Windows and the 32 bit version was currently installed. No no no no no...
I rebooted again and wrangled the 64 bit DVD to install. Once more...I think at this point I'd entered the 25 digit code three or four times at this point...I entered that damned code and managed to reach the custom install selection. I highlighted the partition and told it to format it to a clean slate.
"I can't install there. The partition type is not GPT."
The fuck?
Fine. Delete the partition, Windows. Recreate and format it.
"I can't install there. It's not GPT!"
Flabbergasted that Windows isn't apparently smart enough to create the proper partition itself, I rebooted to OS X and opened Disk Utility. From there I deleted that partition and recreated it, which confirmed it was created by default as a GPT partition...something else must have altered it during the installation process. I formatted it as FAT for good measure.
Time to iterate through my install checklist again. Rebooted with the DVD. Made sure it was 64 bit. Re-enter that damned key again. Custom install. Highlight the partition. "I can't install there. It's not NTFS!"
"Format it, dumbass."
"Okay!"
This time, no error. It installed.
Booted, finished "configuring hardware." Told me in big cartoony letters how wonderful Windows was going to be. Let me configure a user account. No hardware was working beyond the keyboard, mouse and display.
Okay, so it was the non-64 bitness keeping the setup for BootCamp utilities working...let's stick in the disc I had made. This time the original "not gonna do it" error didn't appear; it gave me a different error, that it wasn't meant for my model Mac! In this case it was a better error, though, because now it was the installer giving me a specific error and not Windows puking a generically unhelpful error.
Reboot to recovery boot. Change startup disk to OS X. Reboot.
Reinstall Paragon driver. Reboot. Copy the older version of BootCamp utilities over to Windows. Uninstall Paragon. Select Windows as the startup disk. Reboot.
Unzip the utilities in Windows. Run setup.
It worked.
Holy shit. It worked. It's been two days of downloading and reconfiguring and troubleshooting...and now it was working. No more warning symbols on the network hardware. Webcam worked. Bluetooth. Updated USB. It was all working!
This wasn't even a case of being irritated with the interface as I normally experienced...I'd managed to remember that I had to scroll the pointer along the right side to actually find a menu item I wanted, or to even find the damned shutdown menu. I was accidentally running into the fact that Windows 8 has a cartoony, dumbed down interface to tell me something that also was available from an actual, more familiar control panel version when I accidentally took a wrong turn in the access methods (example: there's a Windows Update that gives you some kind of text wall status, and another that uses the Windows Update control panel...not that either one gives real-time updates on status.) At this point I didn't even have the energy to complain about the unhelpfully generic error messages (YOU KNEW THE PROBLEM WAS RELATED TO A 64 BIT DRIVER ON A 32 BIT OS, YOU BASTARD.)
Some people would blame Apple. I can't. Not just out of fanboyism, but because I really suspect that as far as they're concerned, if you want to run Windows you should have a PC. There's a reason I said BootCamp was a concession...after following Apple news stories for years, reading about Steve Jobs, and paying attention to the details Apple puts into their products, I honestly think they find the notion of Windows on their hardware a distasteful pile of wretchedness they tolerate only to keep gamers from using it as an excuse to refuse trying Apple products. The drivers seem almost half-hearted; they usually work, but tend to lag behind Windows releases when updates are needed. And they aren't necessarily great; for example, failing to support dual-Thunderbolt displays. Windows will see one, but leave the other blank. Why? Apple doesn't seem to care to address it.
And frankly I can see why. The OS is coupled to the hardware. Apple tossed basic support over the fence and shrugged before walking away.
I can't blame Microsoft for the lack of Apple support. It would be nice if they saw more of that hardware by default, but...meh. Apple comes with OS X. Microsoft shouldn't necessarily have to support a system that isn't really meant to run their product.
Nope. The experiences I had getting BootCamp to run is pretty much the kind of pain I expect in trying to shoehorn an operating system Apple doesn't like onto a hardware configuration Microsoft doesn't want to support. Part of me expects this setup to break in the near future...just one update away from another pain point.
What I can say:
I initially told my son he would have to install BootCamp. He should learn how to use his system properly, and if he really wanted this he should do it. And I made no secret that I was disappointed when he didn't make much effort to do this, opting instead to beg until his birthday for us to do this for him. At the time I didn't expect it to be this much of a hassle, though...there's absolutely no way he could have figured this out on his own without a week of study and probably a lot of back and forth on the apple.stackexchange.com site, learning about partitions, formatting, and how drivers interact on systems. A non-problematic install would have been one thing, but something was definitely broken on his system's ability to properly boot from the USB drive, and something with the Apple download site wasn't cooperating half the time with our slow connection to get the proper utilities in the first place.
Windows 8x sucks at giving proper error messages. C'mon...how hard is it to know the error was running a 64 bit installer on a 32 bit operating system?
I'm pretty sure Apple could have created a read/write NTFS driver. In fact, the ability is in OS X...just shut off by default. You can follow some semi-documented procedure to enable it and mount an NTFS volume if you're willing to risk it...I'm just afraid of what risks they're not talking about.
Microsoft is supposedly making it easier...free, even...to get Windows 10. I pray to $DEITY that means they're getting rid of that goddamned 25-character key. I must have entered it five or six times over the course of this ordeal, and every time it was installed before starting a process that would end in NOPE NOT GONNA DO IT HAHA!
Oh, and after getting the key entered the final time and getting drivers working and getting online...Windows still needed activation, so if I didn't get the network driver working...which in one iteration I had this situation...Windows was warning me that I had to call Microsoft to activate it before certain things would work properly. I was even more pissed at the fact this was a purchased, non-pirated, store-box DVD edition of Windows having me enter...and enter...and enter...that 25 character code and it still had another hoop to jump. OS X? It'll reinstall over the Internet by booting to recovery mode. No questions. Just a few clicks. Screw Windows.
If BootCamp fails and you need to reinstall, you may have to delete the partition from Disk Utility. Recreate it from Disk Utility. I reformatted it as a FAT partition so it would be visible from within Windows' setup...if it's using a GUID partition table, Windows should be willing to see and format it.
If you're installing BootCamp utilities separately, make sure you get the correct version for your Mac hardware. Unlike most of the OS X operating system and drivers, BootCamp is finicky.
I suspect Parallels would have worked to bridge my software-transfer problem. Paragon worked in this case, so far without cruft being visible after the uninstaller was run. Trying to get pain-in-the-ass software like this is great for reminding you that you can get creative to solve problems. The stress probably does shorten your life a little, too, though.
Last thing...don't run BootCamp unless you really, really need to. Parallels is a fantastic product. VirtualBox works well most of the time and for most purposes. BootCamp forces you to get meh driver support and sacrifice a fixed portion of your hard drive. If you're going to use it, have a really good reason to do so.
Now if you'll excuse me, I'm going to see if I have some more Bacardi in the kitchen. This installation of Windows has left me with an extraordinary amount of stress to burn off...
Saturday, July 4, 2015
Revisiting the Haiku Operating System
In 1996 Apple was looking for the successor to Mac OS. Project Copland was deemed a failure, and Apple decided to search for a third-party operating system on which to base a modern operating system. If you have any interest in operating systems or computing history, there's plenty of information to be found surrounding the (broken) promises of Copland and Gershwin.
Choices were narrowed down to two operating systems; Be, Inc's BeOS, spearheaded by an ex-Apple executive name Jean-Louis Gassée, and NeXT with their NeXTSTEP operating system, pushed by another ex-Apple employee named Steve Jobs.
I'm pretty sure you can figure out which operating system won the contest.
Be, Inc never recovered from the loss, and after a swift decline it was swallowed by Palm and eventually digested into nothing. I had played with BeOS R5 and was very impressed; Be had created a fast, single-user, lightning fast, multithreaded, speedy multimedia operating system. They initially created a BeBox machine specifically geared to run their operating system; notable to the case design were large "blinkenlight" stripes that indicated CPU usage. And did I mention it was fast?
BeOS was really a geeky tinkerer's dream; the BeBox even had a "geek port" for hardware hackers to play with programming various electronics with minimal danger to the system (it had 3 fuses backing it on the motherboard.) Be, Inc kept shifting targets...porting BeOS from the BeBox to the Mac PowerPC, then to the Intel platform...it retained a small but dedicated group of hackers determined to keep the OS alive.
When Be finally gave its final death rattle, a group of fans reimplemented BeOS in what is now known as Haiku. The project started in 2001, and in 2008 it became "self hosting." I grew nostalgic for the project and curious at what the current state was, so I ventured to the website and downloaded the R1/Alpha 4.1 version released on November 14, 2012.
I tinkered with some VirtualBox settings (to virtualize the installation...I didn't have a hardware box to spare), configured it with 512MB RAM and a 5GB hard drive (believe it or not, both are more than the minimum requirements...) and a bridged network adapter. Another neat hack I found online; Haiku isn't really "VirtualBox-aware", so there's no seamless mouse integration (you click on the desktop and it captures the pointer until you hit the key combination to release it), but it does understand the USB tablet as a pointer. Tell VirtualBox to use that as the pointer and you get the seamless mouse integration functionality.
The bootup time was fast, despite emulating a "live CD" boot. The installer formatted the drive and ran without hiccups. It removed the virtual CD, rebooted, and voila'...Haiku!
It only took a few moments to verify that the network connection was working (and was indeed bridged, so it looked like another machine on the network rather than a NAT device behind my computer which in turn was NAT'ed again to the Internet; sometimes things don't like double-NAT weirdness.) I decided to try a simple accessibility check by giving the default user a password then enabling SSHD on Haiku. I was able to SSH to a terminal from my Mac without any problem.
The alpha came with a nice selection of some basic applications.
If you're a C++ fan, you'll love Haiku. It's not only written in C++, but it includes the "BeBook", essentially an API reference to give programmers a reference for writing more Haiku applications. The command line tells me that gcc version 2.95.3-haiku-121101 is included...
Obviously there's a web browser called WebPositive included, as you can see that it is being used to view the BeBook. It's not the most functional or up to date browser, but for the most part it's usable.
Haiku also includes a user guide so you can learn how to navigate workspaces (virtual desktops! With their own backgrounds and resolutions!) and find files. Just poking around the interface yielded some nice surprises in terms of what I could do with the operating system.
There are lots of little toys to explore, from SSH to web browser to a spinning teapot demonstration and an IRC client. There's even a web server! And it appears that it is possible to build Haiku from Haiku; the website has instructions on how to compile it from a self-hosted view or cross-compiled from several other platforms. It's really kind of amazing...if you enjoy C++ programming, maybe you should check out Haiku.
One of the main things to keep in mind about BeOS/Haiku is that it is truly meant to run as a user's operating system, not a multi-user operating system. Windows has the concept of user login. Linux, and the BSD roots in Darwin (OS X), also ingrained the idea of multi-user thinking in computing. Commonplace ideas like a home directory aren't really used in Haiku because it doesn't expect more than one person to use the device. Anything that was done on OS X or Windows to separate user configurations or add separation for security isn't necessarily implemented on Haiku, leading to some confusion when poking around (like, why is my home directory /boot/home? There's no user folder...)
That said, it sounded like there were plans for some limited forms of multi-user support being planned for a future release.
After poking for a bit and being wowed by the speed at which it runs (given that it was running in a virtual machine with minimal processors allocated...Haiku is heavily multithreaded, so it likes more processors to run on) I started looking for an updater. Apparently the alpha release didn't have an update system; given the number of other applications on the system I was a little surprised that hadn't been added along the way.
In addition to the alpha there are "nightly builds"; according to the online documentation, there's a package management system called pkgman that will update your system and let you install applications from a repository. The alpha release works fairly well, let's try the nightly build! Latest features!
That...was a mistake.
Like the alpha release, it installed without much of a hiccup. But the network refused to come up. It just stayed stuck on "configuring." After cycling through all the available network cards VirtualBox can emulate, I changed the network mode from Bridged to NAT, and it started working. It made me sad to lose bridging support.
I wanted to use a SSH session so I could refer to some documentation on my Mac and paste commands from reference sites into Haiku. I added the password to the default user and tried to launch SSHD...and it failed. I couldn't find a reason for it, nor could I find a fix online in their forums.
I wanted to join the forum so I could post a question about it; naturally this means a confirmation email. A confirmation email that never came. I sent a message through the "contact us" form, and still didn't hear anything back. (Of course I checked the spam folders and junk folders. I never found an email from them.)
Basically the nightly builds, running on Virtualbox, were broken. And I couldn't get help from the community site because it seems they are broken too. I even had some odd errors pop up as it booted and when I tried changing settings about an operating system component failing. Seemed rather random, but at the time I was frustrated with the components that were broken. And yes, I'm aware that the nightly builds explicitly warn of regressions and broken parts; I simply hadn't expected what for me would be multiple showstopper regressions. The first things I had tried doing...network access, and enabling SSHD...both failed spectacularly, as did the act of trying to join the forums to ask about possible fixes. It left me questioning if this was really a nightly build or if the project had zombied along the way and no one updated the website to say the project had essentially shut down.
I reverted back to the alpha R4 release to play around with it some more. It's a beautiful operating system...if I won the lottery I'd love to fund more work on it. The R4 alpha is usable enough for basic work, and if you're a C++ developer it's probably worth playing around in. Or if you're a student learning C++ it might be worth using since GCC is installed.
Seeing as I've been playing with Go recently, I thought it would be fun if there were a Go port for Haiku available; of course, that was a very long shot and my expectations were low. The only reason I thought about it was because Go has a number of platforms on which it currently works, including Plan 9.
It turns out, according to the forums, there was work done by someone trying to port an older version of Go to Haiku. It doesn't look like the person completely succeeded, though. That was a shame, since Go with its goroutines seems to heavily support the kind of multithreading that BeOS, and Haiku, were made for.
If you're a fan of operating systems and like playing with a piece of history, I highly recommend giving Haiku (the R1Alpha4 release) a try. It's usable. Its fast. And it's got a lot of nice touches, especially when you consider the history of the operating system.
Side note - I see in the Haiku blogs that a report was recently published, so I'm guessing the project is still alive and updating. Perhaps I am simply running into a number of regressions with their nightly-builds that happen to really converge against the VirtualBox platform? I know that if I really wanted to pursue the issue there appears to be an IRC channel available for questions, or maybe if I dig around I could find another email address to try getting the forum thing sorted out, but then it's a question of how much effort I want to put into pursuing this...
I'm pretty sure you can figure out which operating system won the contest.
Be, Inc never recovered from the loss, and after a swift decline it was swallowed by Palm and eventually digested into nothing. I had played with BeOS R5 and was very impressed; Be had created a fast, single-user, lightning fast, multithreaded, speedy multimedia operating system. They initially created a BeBox machine specifically geared to run their operating system; notable to the case design were large "blinkenlight" stripes that indicated CPU usage. And did I mention it was fast?
BeOS was really a geeky tinkerer's dream; the BeBox even had a "geek port" for hardware hackers to play with programming various electronics with minimal danger to the system (it had 3 fuses backing it on the motherboard.) Be, Inc kept shifting targets...porting BeOS from the BeBox to the Mac PowerPC, then to the Intel platform...it retained a small but dedicated group of hackers determined to keep the OS alive.
When Be finally gave its final death rattle, a group of fans reimplemented BeOS in what is now known as Haiku. The project started in 2001, and in 2008 it became "self hosting." I grew nostalgic for the project and curious at what the current state was, so I ventured to the website and downloaded the R1/Alpha 4.1 version released on November 14, 2012.
I tinkered with some VirtualBox settings (to virtualize the installation...I didn't have a hardware box to spare), configured it with 512MB RAM and a 5GB hard drive (believe it or not, both are more than the minimum requirements...) and a bridged network adapter. Another neat hack I found online; Haiku isn't really "VirtualBox-aware", so there's no seamless mouse integration (you click on the desktop and it captures the pointer until you hit the key combination to release it), but it does understand the USB tablet as a pointer. Tell VirtualBox to use that as the pointer and you get the seamless mouse integration functionality.
The bootup time was fast, despite emulating a "live CD" boot. The installer formatted the drive and ran without hiccups. It removed the virtual CD, rebooted, and voila'...Haiku!
 |
| Pretty! |
The alpha came with a nice selection of some basic applications.
 |
| Activity Monitor + the app menu |
 |
| ♪ Do you wanna build a program? ♪ |
Haiku also includes a user guide so you can learn how to navigate workspaces (virtual desktops! With their own backgrounds and resolutions!) and find files. Just poking around the interface yielded some nice surprises in terms of what I could do with the operating system.
 |
| Ooh! A Quitter with graphs! |
One of the main things to keep in mind about BeOS/Haiku is that it is truly meant to run as a user's operating system, not a multi-user operating system. Windows has the concept of user login. Linux, and the BSD roots in Darwin (OS X), also ingrained the idea of multi-user thinking in computing. Commonplace ideas like a home directory aren't really used in Haiku because it doesn't expect more than one person to use the device. Anything that was done on OS X or Windows to separate user configurations or add separation for security isn't necessarily implemented on Haiku, leading to some confusion when poking around (like, why is my home directory /boot/home? There's no user folder...)
That said, it sounded like there were plans for some limited forms of multi-user support being planned for a future release.
After poking for a bit and being wowed by the speed at which it runs (given that it was running in a virtual machine with minimal processors allocated...Haiku is heavily multithreaded, so it likes more processors to run on) I started looking for an updater. Apparently the alpha release didn't have an update system; given the number of other applications on the system I was a little surprised that hadn't been added along the way.
In addition to the alpha there are "nightly builds"; according to the online documentation, there's a package management system called pkgman that will update your system and let you install applications from a repository. The alpha release works fairly well, let's try the nightly build! Latest features!
That...was a mistake.
Like the alpha release, it installed without much of a hiccup. But the network refused to come up. It just stayed stuck on "configuring." After cycling through all the available network cards VirtualBox can emulate, I changed the network mode from Bridged to NAT, and it started working. It made me sad to lose bridging support.
I wanted to use a SSH session so I could refer to some documentation on my Mac and paste commands from reference sites into Haiku. I added the password to the default user and tried to launch SSHD...and it failed. I couldn't find a reason for it, nor could I find a fix online in their forums.
I wanted to join the forum so I could post a question about it; naturally this means a confirmation email. A confirmation email that never came. I sent a message through the "contact us" form, and still didn't hear anything back. (Of course I checked the spam folders and junk folders. I never found an email from them.)
Basically the nightly builds, running on Virtualbox, were broken. And I couldn't get help from the community site because it seems they are broken too. I even had some odd errors pop up as it booted and when I tried changing settings about an operating system component failing. Seemed rather random, but at the time I was frustrated with the components that were broken. And yes, I'm aware that the nightly builds explicitly warn of regressions and broken parts; I simply hadn't expected what for me would be multiple showstopper regressions. The first things I had tried doing...network access, and enabling SSHD...both failed spectacularly, as did the act of trying to join the forums to ask about possible fixes. It left me questioning if this was really a nightly build or if the project had zombied along the way and no one updated the website to say the project had essentially shut down.
I reverted back to the alpha R4 release to play around with it some more. It's a beautiful operating system...if I won the lottery I'd love to fund more work on it. The R4 alpha is usable enough for basic work, and if you're a C++ developer it's probably worth playing around in. Or if you're a student learning C++ it might be worth using since GCC is installed.
Seeing as I've been playing with Go recently, I thought it would be fun if there were a Go port for Haiku available; of course, that was a very long shot and my expectations were low. The only reason I thought about it was because Go has a number of platforms on which it currently works, including Plan 9.
It turns out, according to the forums, there was work done by someone trying to port an older version of Go to Haiku. It doesn't look like the person completely succeeded, though. That was a shame, since Go with its goroutines seems to heavily support the kind of multithreading that BeOS, and Haiku, were made for.
If you're a fan of operating systems and like playing with a piece of history, I highly recommend giving Haiku (the R1Alpha4 release) a try. It's usable. Its fast. And it's got a lot of nice touches, especially when you consider the history of the operating system.
Side note - I see in the Haiku blogs that a report was recently published, so I'm guessing the project is still alive and updating. Perhaps I am simply running into a number of regressions with their nightly-builds that happen to really converge against the VirtualBox platform? I know that if I really wanted to pursue the issue there appears to be an IRC channel available for questions, or maybe if I dig around I could find another email address to try getting the forum thing sorted out, but then it's a question of how much effort I want to put into pursuing this...
Subscribe to:
Posts (Atom)