Jul 26 2012

Kashi soft cereal bars – cherry vanilla

I am continuously on the lookout for new products that are healthy, yet still have some type of taste. Seeing as I generally watch my fat intake (especially saturated fat) more than anything else, I look for foods that are low in fat, even if they are a bit higher in carbohydrates, calories, sugars, et cetera. One of my favourite brands of healthier snacks is Kashi, and I particularly like their snacks (as opposed to their cereals or other meals).

At the same time that I purchased the Banana Chocolate Chip Soft n’ Chewy bars, I picked up a few boxes of their soft cereal bars (in different flavours). One of the flavours that’s currently available is Cherry Vanilla, and I hope that it is one they decide to keep making for a long time!

Kashi Cherry Vanilla soft cereal bar

These bars have a great flavour combination with the prominent cherry, and a subtle vanilla taste. Normally, an after taste has a somewhat negative connotation, but in this case, I think that the vanilla after taste is very nice. The two flavours go together very nicely, and it’s not a combination that I’ve seen in cereal bars from other companies. The bars are a little bit dry by themselves (but I find most cereal bars to be that way), but that is easily overcome with either a glass of milk or by putting the bars in the microwave for ten seconds or so.

The bars are 35g, have 120 calories (30 from fat), and 3g of total fat (0 saturated / 0 trans). There are 3g of fibre per bar, but it is all insoluble fibre (though that is great for digestion). They also have 23g of carbs, 9g of sugars 2g of protein. For those watching carbs, they might not be the best choice, but then again, cereal bars in general are relatively high in carbs. Overall, I find them to be a fairly nutritious way for me to snack, and to have something that satiates my need for something sweet at the same time. 🙂

Cheers,
Zach

Jul 25 2012

Revisiting screen lockers and patching a security risk

Recently, I posted about two screen lockers that I’ve used in the past (xtrlock and slock). There has been some great discussion about these lockers, and some potential security problems that come along with using them. One very prominent issue regarding using screen lockers without login managers was raised by a reader, and I want to address it in this separate post.

Just as some background information, many people prefer to use login managers (also known as display managers) in order to be greeted by a graphical login prompt. To use these managers, the X Window System must be started as one of the final steps of the boot process (either by setting the default runlevel to 5 in inittab, setting the display manager to start via the rc system / a daemon, or another method). Some people don’t like the idea of a login manager starting automatically at the end of the boot process, and would prefer to simply be greeted with a terminal login prompt. For those users, it is obviously still necessary to log in as a valid user, but then to start an X session (for their respective graphic environment), one must issue the startx command.

The problem with screen lockers and the startx method of starting Xorg is that it presents a large security flaw. I mentioned in the previous post that one can switch to a different virtual terminal (by using the CTRL+ALT+F# key combination) and log in as a different user. Unless that user can become root and kill the screen locker, though, there’s no problem. However, when Xorg is started using startx, a person can switch to the virtual terminal that issued the startx command, and just hit CTRL+C to kill it. They will then be at the prompt for the user that issued the command, and won’t have to log in. Oops…

A good workaround for this problem is to start Xorg and make sure that the terminal is locked if X is killed. This workaround relies on the package vlock, which is a terminal locking application. For it to work properly, instead of issuing the standard startx command, one needs to issue startx ; vlock. That way, if a person switches to the virtual terminal that started the X session, and hits CTRL+C, it will kill X, but that will automatically start vlock, and subsequently, present the person with nothing more than a login prompt. What’s more, that person will have to enter the password for the user that started the X session.

There might be more elegant methods for fixing this problem, including a script to disable virtual terminal switching when the screen locker is called, and I’ve been looking into such methods. If anyone has further suggestions regarding workarounds, or more permanent solutions, please feel free to comment.

Cheers,
Zach

Jul 24 2012

Countdown to the job transition

If you frequent the Z-Issue, you may have noticed that there is now a counter in the sidebar. I received some news recently, and to me, it’s really exciting (enough for me to put a countdown widget on the ol’ blog). 🙂 I’ve been a Senior Linux Engineer for quite some time, and my current employer has decided to transition my role from Systems Engineering at the Lab level to a completely new position focusing on various needs of the organisation. Some of my responsibilities will be: maintenance and improvements to our internal systems (primarily Linux); internal documentation of our technologies and procedures; training of our newly-hired employees, as well as ongoing training for our current staff; working with our various development teams on streamlining their processes, and a lot of other fascinating areas.

Along with this great promotion, I get to move back to a city that I really enjoy, and think of as one of my home towns–Saint Louis, Missouri, United States. A have a lot of family and friends there, and really can’t wait to get back to see all of them on a regular basis. The combination of the new responsibilities, new title, being home, and getting to work remotely makes for an ideal situation toward which I’ve worked for many years.

Not all that much longer now. 🙂

Cheers,
Zach