A Facebook friend pointed out the following news article:
In Memoriam: "Reading Rainbow"
One of the many good shows I remember from my early childhood....
Friday, August 28, 2009
Ordering McNuggets
McDonald's chicken nuggets are an interesting price conundrum. These days, most people are been conditioned to automatically believe that the higher the quantity of a product you buy, the more value you get. While this is usually true, saving us the work of having to calculate unit prices for everything, this isn't necessarily so with McNuggets. It's been awhile since I noticed this; perhaps it was originally during my vacation to Hawaii two summers ago (prices in Hawaii are high for just about everything because things have to be imported), but whatever the case, because of the ubiquitous dollar menu at all McDonalds, a 4 piece McNuggets can be bought for $1. At least in my geographic area, all the higher quantity purchases have unit prices higher than $0.25. In fact, it is more cost effective to purchase 3x 4 piece McNuggets than it is to purchase the box of 10 (and this is true for the 6 and 20 quantities as well). There is never a case in which I would get a better value buying a box that had more than 4 nuggets in it. The nuggets aren't any different in size or taste. For the nitpickers, the only noticeable differences are that you get a few more boxes that have the words "Happy Meal" on them (since Happy Meals get 4 McNuggets). Just thought I'd share this cost saving tip with those that hadn't noticed this already :)
Thursday, August 13, 2009
Google DragRacer
A friend pointed out an interesting Google Maps street view of what appears to be a race in progress. Looks like a Google employee had a lot of fun that day!
Monday, August 10, 2009
Google Apps and Privacy
About a week ago, there was an interesting Slashdot posting about privacy of data and Google Apps, specifically in respect to HIPAA compliance and legal liability. Based on the very interesting train of comments, it seems that using Google Apps for medical data would not be HIPAA-compliant because the data is not stored in an encrypted form. I certainly don't claim to be very familiar with either HIPAA or Google's Terms of Service, but that does sound like it could be a problem.
More importantly, though, is the point raised that Google employees can read your data. This is something that most people don't really think about. I had an interesting conversation with a fellow TJ student once. As a sysadmin, I had access to the mail system, and I mentioned that the nature of having administrator access was that we could read students' TJ e-mail if we wanted to, but that we were highly unlikely to do so. This student wasn't very comfortable hearing this, so I also brought up that using any other mail system like Gmail had the same issue. For some reason, this person was more comfortable with strangers having access to her data than a fellow student. If I remember correctly, the rationale was that some information (e.g. personal relationships, etc.) could be more damaging in my hands than in the hands of a total stranger. At the same time, that's saying you would trust a random stranger with your most personal secrets more than you would another responsible student (because becoming a student sysadmin is not as easy as "here you go") at the school you attend. And yet, as illogical as that seems, more and more people opt to go this route. For instance, people will blog or post things online but then are surprised when other people find it and it gets used against them (the classic example is a prospective employer finding an embarrassing photographs of or information about you online).
Back to the original topic, then. While Google Apps offers a lot of benefits, including low cost (it's free unless you opt for a premium version) and familiarity (just about everyone has a personal Gmail account and finds Google products easy to use), there are times you want to consider the implications of putting things in the hands of people that you don't really know. There is a reason, after all, that passwords and other sensitive information aren't supposed to be sent in e-mails. But let's say that every employee that works for a company handling your data is trustworthy. You still have to deal with the possibility that data is accidentally mishandled or lost, because even with the best intentions, accidents do happen ("lost laptop with thousands of Social Security Numbers" ring a bell?). That is, after all, the definition of an accident.
So the next time you choose to use a public service for storing or transmitting potentially sensitive information, consider not only the benefits, but also the implications of doing so. And if you're in healthcare, I advise you to do your research thoroughly, and consider whether or not your patients would approve of the way your data is being handled. But who knows, these days it's possible plenty of people would be quite happy with their private health information in the hands of computer nerds they've never met.
More importantly, though, is the point raised that Google employees can read your data. This is something that most people don't really think about. I had an interesting conversation with a fellow TJ student once. As a sysadmin, I had access to the mail system, and I mentioned that the nature of having administrator access was that we could read students' TJ e-mail if we wanted to, but that we were highly unlikely to do so. This student wasn't very comfortable hearing this, so I also brought up that using any other mail system like Gmail had the same issue. For some reason, this person was more comfortable with strangers having access to her data than a fellow student. If I remember correctly, the rationale was that some information (e.g. personal relationships, etc.) could be more damaging in my hands than in the hands of a total stranger. At the same time, that's saying you would trust a random stranger with your most personal secrets more than you would another responsible student (because becoming a student sysadmin is not as easy as "here you go") at the school you attend. And yet, as illogical as that seems, more and more people opt to go this route. For instance, people will blog or post things online but then are surprised when other people find it and it gets used against them (the classic example is a prospective employer finding an embarrassing photographs of or information about you online).
Back to the original topic, then. While Google Apps offers a lot of benefits, including low cost (it's free unless you opt for a premium version) and familiarity (just about everyone has a personal Gmail account and finds Google products easy to use), there are times you want to consider the implications of putting things in the hands of people that you don't really know. There is a reason, after all, that passwords and other sensitive information aren't supposed to be sent in e-mails. But let's say that every employee that works for a company handling your data is trustworthy. You still have to deal with the possibility that data is accidentally mishandled or lost, because even with the best intentions, accidents do happen ("lost laptop with thousands of Social Security Numbers" ring a bell?). That is, after all, the definition of an accident.
So the next time you choose to use a public service for storing or transmitting potentially sensitive information, consider not only the benefits, but also the implications of doing so. And if you're in healthcare, I advise you to do your research thoroughly, and consider whether or not your patients would approve of the way your data is being handled. But who knows, these days it's possible plenty of people would be quite happy with their private health information in the hands of computer nerds they've never met.
Audacity on Solaris
I finally got Audacity (both stable 1.2.6 and beta 1.3.7) compiled and working on Solaris 10, albeit with some minor remaining issues. While 1.3.8 is already out, I opted not to compile it since I had already started working with 1.3.7 and 1.3.8 is also the first release after the project's announcement that PortAudio v18 was no longer supported in the 1.3 branch. We need PortAudio v18 to support Solaris audio framework since Solaris 10 does not have OSS support, at least for Sun Ray. These packages should also work on OpenSolaris, using the legacy Solaris audio interfaces.
Click here for the SVR4 package downloads and a README file with dependency and known issue information. As with the VLC package from a few days ago, dependencies are not included, and I would appreciate if someone would be willing to mirror these files.
Click here for the SVR4 package downloads and a README file with dependency and known issue information. As with the VLC package from a few days ago, dependencies are not included, and I would appreciate if someone would be willing to mirror these files.
Saturday, August 8, 2009
High Tech Schools
TVNZ: Wired for the future
I had trouble getting the Flash version to load, possibly because the server is half way around the world from where I am. The Windows Media link did work. For those on non-Windows systems, here's a direct link to the Windows Media version of the video. Of particular note are the Sun Rays running what appears to be GNOME with Firefox 2. In addition, it seems that they use Zimbra for their e-mail.
I had trouble getting the Flash version to load, possibly because the server is half way around the world from where I am. The Windows Media link did work. For those on non-Windows systems, here's a direct link to the Windows Media version of the video. Of particular note are the Sun Rays running what appears to be GNOME with Firefox 2. In addition, it seems that they use Zimbra for their e-mail.
Thursday, August 6, 2009
VLC on Solaris 10
Yes, it works! All the little things I had to do to get it compiled I've filed on VLC Trac (tickets 3027 through 3040). As of the time of this post, five issues have already been fixed in SVN. There might still be some other runtime issues that I haven't found, but for the most part it seems to be working.
I've uploaded SVR4 packages (installs in /usr/local) for VLC on both x86 and SPARC. Note that it does have dependencies! For any audio support, you will minimally need SDL. ncurses is needed for the ncurses interface, QT4 is needed for the standard GUI, libmad is needed for MPEG decoding (including MP3), ffmpeg is needed for a lot of video formats, etc. I am currently not supplying these dependencies, but if I get enough requests to, that can change. The package specifies the maximum set of packages that are dependencies (that is, if some are missing, VLC may still work but not all of the plugins will). For those not very familiar with the various community-based package sources for Solaris, SMC packages are at sunfreeware.com and CSW packages are from either opencsw.org or blastwave.org. STJ packages are ones that I compiled at TJHSST (VLC included), and are not presently accessible outside of TJ.
Enough talk already! Click here for the downloads. I would appreciate it if someone was willing to mirror these packages since this site has limited bandwidth. Feel free to let me know what you think of the packages! They should work on OpenSolaris as well.
UPDATE 8/11/2009 10:00 PM:
I've added a binary SVR4 package for QT4 (GCC) since it isn't as easily found and is also a very lengthy compile. I've added a README at the site as well for some additional information, including tips and pointers to get your dependencies. For OpenSolaris users, you should be able to get a working VLC with no source code compilation needed!
I've uploaded SVR4 packages (installs in /usr/local) for VLC on both x86 and SPARC. Note that it does have dependencies! For any audio support, you will minimally need SDL. ncurses is needed for the ncurses interface, QT4 is needed for the standard GUI, libmad is needed for MPEG decoding (including MP3), ffmpeg is needed for a lot of video formats, etc. I am currently not supplying these dependencies, but if I get enough requests to, that can change. The package specifies the maximum set of packages that are dependencies (that is, if some are missing, VLC may still work but not all of the plugins will). For those not very familiar with the various community-based package sources for Solaris, SMC packages are at sunfreeware.com and CSW packages are from either opencsw.org or blastwave.org. STJ packages are ones that I compiled at TJHSST (VLC included), and are not presently accessible outside of TJ.
Enough talk already! Click here for the downloads. I would appreciate it if someone was willing to mirror these packages since this site has limited bandwidth. Feel free to let me know what you think of the packages! They should work on OpenSolaris as well.
UPDATE 8/11/2009 10:00 PM:
I've added a binary SVR4 package for QT4 (GCC) since it isn't as easily found and is also a very lengthy compile. I've added a README at the site as well for some additional information, including tips and pointers to get your dependencies. For OpenSolaris users, you should be able to get a working VLC with no source code compilation needed!
Subscribe to:
Posts (Atom)
Posts
