I was trying to install a virtual machine using the latest VirtualBox on a Windows 7 Host. The host was also running OpenDNS DNSCrypt 0.0.6 client. The guest operating system should be Debian/LXDE. Installation went fine until the installer tried to contact Debian mirrors to fetch missing packages.
It couldn’t find them. Like the common system administration mantra says:
Everything is a DNS problem.
So at the OpenDNS DNSCrypt client dashboard I (temporarily) disabled the DNS over TCP option and the installation continued smoothly. The same thing does not happen with OS X Mavericks as the host operating system. After the installation is finished, you can reenable DNS over TCP for DNSCrypt. The guest operating system’s resolver sees no issues with this.
I am posting this short note because it may bite others out there.
I bought a 8GB SD card for my Raspberry Pi and happily dd’ed the Raspbian image to it. But it did not boot. @namp and @eliaschr suggested that I re-dd-ed (redid?) the image to the disk. But I know how to run dd(1), right?
Yes and no :(
I run dd.exe from a windows machine:
C:\TEMP> dd.exe if=2013-09-25-wheezy-raspbian.img of=\\.\e:
Ding! The above does not start writing from the beginning of the disk. It starts writing from the beginning of the E:\ partition. I dd-ed the image from a Mac and all boot well.
I suppose (but have not yet checked) that had I used the \\.\path\to\physical\drive path, I would not have bumped into this.
- A Windows 2008 R2 server running Exchange 2010
- The Domain Administrator’s Password was changed and then forgotten.
So now we are completely locked out of the system. To make things worse, the Offline Windows Password and Registry Editor could not identify the SCSI controller.
I’m sure I’ve blogged about this before, but I cannot find it right now. Anyway the following tweet:
The University of North Carolina has finally found a network server that, although missing for four years, hasn’t missed a packet in all that time. Try as they might, university administrators couldn’t find the server. Working with Novell Inc. (stock: NOVL), IT workers tracked it down by meticulously following cable until they literally ran into a wall. The server had been mistakenly sealed behind drywall by maintenance workers.
… θα βρεις έναν Έλληνα. Ο Δημήτρης Στάικος, φίλος από τα παλιά, ένα έτος μεγαλύτερος και hacker extraordinaire, αντιπρόεδρος του 1394 Trade Association (Firewire για όποιον δεν τα πάει καλά με τα νούμερα).
In this thread Samuel J. Greear asks:
What has drawn you to use the DragonFly BSD operating system and/or participate in its development by following this list? Technical features, methodologies, something about the community? I suspect the HAMMER filesystem to be the popular choice, but what other features affect or do you see affecting your day to day life as an administrator, developer, or [insert use case here], now or in the future?
Since I do not follow the mailing list I will answer here: Well it is of BSD origin! The real reason I used DragonFlyBSD years ago, was that we needed to run pf on the machine and DragonFly was the only BSD that installed on it (with some tweaks though). So simple. It also felt a lot like FreeBSD-4 (for some inexplicable reason, I was never really happy with FreeBSD-5, never installed version 6, returning to using it on production systems in versions 7 and 8). Plus, I got to submit a (minor) bug report :)
I really miss not running DragonFly these days.
One way to install Debian on a machine that requires the bnx2 network driver, is to download the firmware, place it on a USB stick and continue as instructed by the Debian Installer. Another quick trick is to use a USB ethernet card and proceed with installing Debian. Then apt-get install firmware-bnx2 and reconfigure the network interfaces appropriately.
ifconfig gif0 create gifconfig gif0 inet Client_IPv4_address Server_IPv4_address ifconfig gif0 inet6 Client_IPv6_address Server_IPv6_addrees prefixlen 128 route -n add -inet6 default Server_IPv6_address ifconfig gif0 up
Tested with DragonFlyBSD 2.4.1
#USENIX @AnnualTech M. Renzelmann Decaf: Moving Device Drivers to a Modern Language (Java). He says performance impact is 1%
talks about “Decaf: Moving Device Drivers to a Modern Language” which describes a system where large parts of a driver can be written in a better language than C, the example here being Java.
I was certain that this was not the first time I had read about such an idea. This weekend I was able to go through my archive and find out the reference. Back in January 1997 in the NT Insider (Volume 4, Issue 1) Peter Viscarola, while criticizing the multitude of startups founded by anyone who could code a Java applet (this was a pre-dot-boom era remember) wrote:
It’s obvious that we are missing a real opportunity here to capitalize on the convergence of these trends. We need to immediately fund a start-up company to develop a package for writing Windows NT drivers in Java. THINK of it! We could have processor architecture independent device drivers that don’t even need to be recompiled in order to support X86, PPC, and Alpha machines! Amazing! We could create a visual driver development environment, complete with cute animated assistants. And, the drivers could probably have a visual component to them, so you could actually see your toaster-oven driver doing its work. Cool! THEN we could all be challenged, and have fun, and get rich at the same time. Wow! Why didn’t I think of this before?
It would be nice if we could see Peter’s views on the subject 12 years later.