xCellence in bits

Ever removed a SCSI disk from a Linux box? No? Well, you could. After all SCSI is designed with hotplug in mind. There’s even a handy function in the Linux kernel to remove a device which powers it down and then removes from the list.
Today we hardly have SCSI disks at home but we have SATA disks which use the SCSI disk layer and - originally - are hotplug-capable.
It’s simple. You just issue the command:

echo "scsi remove-single-device h c i l" > /proc/scsi/scsi

where “h” is host controller, “c” is channel, “i” is id, “l” is LUN. Adding is the same, but you use “add-single-device” instead.
Now, how would you know which disk you want to remove? Well, you could dig it up from kernel log, read /proc/scsi/scsi or just by guessing. Well this is what I got fed up a bit. Okay, it’s no big deal, you think twice before trying to remove anything at all.
Another issue is, after you removed the disk and would like to add it again - or another disk - the system may reinsert it under a different device name! Normally you won’t care, since it doesn’t matter if it’s sda or sdc if it’s there. Well, a RAID subsystem will. Since the disk won’t be accessible under its previous name there will be just a little use of the newly inserted disk. More precisely, none at all.

There are several “workarounds” for this problem. One was devfs which recently was removed from the kernel. Hm. found another one, which is an userspace program, called scsidev. It recreates the device nodes with persistent device naming - you know, names like won’t change and will reflect the device position in the system. Well after a removal and reinsert you need to run it again, since the major/minor numbers will change for the newly inserted device.
Another one is udev, which uses sysfs and runs in userspace. It creates a virtual /dev and updates it in real time - or at least when a hotplug event occurs.

The last one was a bit too big for my needs, so I made up this little patch which registers the scsi disks with the name like “h0c0i0l0″ which stands for host 0 channel 0 id 0 LUN 0. It’s guaranteed to be the same even right at bootup - when the RAID system initializes itself or when that d*mn pendrive you left there would push all the device names aside.
With sysfs, you can make up a small script which creates the needed device nodes - if you don’t use udev already which does the same, basically.

Since the kernel is GPL, I release the patch for fun or maybe someone will find it useful. It’ so small that you can cut/paste it from here. If you don’t know how to apply it, you don’t need this patch.

This part is about a CPU that is still very actively developed and maintained.

The SPARC stands for Scalable Processor ARChitecture which was originally designed in 1985 by Sun Microsystems.

This is also a CPU that started its live as a 32-bit one and later became a fully 64-bit implementation. It’s design is very unique, even among the weird world of CPUs.

A typical SPARC processor has 128 general-purpose registers and 32 of them are visible for software. 8 of them are global registers, one of them is hardwired to 0 - just like in MIPS - so only 7 are usable as normal registers. The remaining 24 is called stack of registers. These registers form a register window and at function call this register window is moved in the register stack. Each register window has 8 local registers and shares 8 registers with the other register windows. The shared registers are used for parameter passing for functions and the local registers are used for retaining local values in between function calls.

The SPARC is a clean big-endian design, however later it got little-endian access feature too. The SPARC CPU is versioned with a V and a number after it. It always had a nickname too, but generally the major versions are started from V7.

The first SPARC appeared in 1986 and was running between 14-40MHz. The V8 appeared in 1992, quite a few years after the V7. It featured clock speed of 40-50MHz and separeted dcache and icache (4K). The V6 had 0-128K unified L1 cache.

The V8 was the first MicroSPARC I CPU, codenemed “Tsunami”.

The next V8, SuperSPARC, codenamed “Viking” appeared in 1992 too and the dignificant difference was the L2 cache, between 0-2048K. There was a SparcLITE too with small cache a small operating voltage.

The next V8 SPARCs were hyperSPARC “Colorado 1″, microSPARC II “Swift”, hyperSPARC “Colorado 2″, superSPARC 2 “Voyager”, hyperSPARC “Colorado 3″, TurboSPARC, all of them featured clock speed up to 180MHz and various sized L2 and L1 caches. Depending on the manufacturer, the V8 specification implemented in many ways as its unique naming scheme shows. The “Last V8″ came in 1995.

The V9 SPARC began with UltraSPARC I “Spirfire” in 1995. It was a 64-bit design already. It had a clock speed of 143-167MHz and 512K-1M L2 cache. The V9 SPARCs were UltraSPARC I “Hornet”, hyperSPARC “Colorado 4″, SPARC64, SPARC64 II, SPARC64 III (getting enough already?) , UltraSPARC IIs “Blackbird”, UltraSPARC IIs “Sapphire Black”, UltraSPARC IIi “Sabre”, UltraSPARC IIi “Sapphire Red”, UltraSPARC IIe “Hummingbird”, UltraSPARC IIi “IIe+” and the list goes on…Depending on the manufacturer, the V9 realized in many forms as well.

The remarkable difference was the SPARC64 IV in 2000, this time by Fujitsu. It was clocked at 450-810MHz with 2048K L2 cache. It was the first radical new implementation to the previously listed seemingly faster and faster V9 SPARCs.
The “answer” arrived a year later from Sun itself: UltraSPARC III “Cheetah” running at 600Mhz, with a massive 8192K L2 cache. Till the UltraSPARC IV “Jaguar” in 2004 there were similar steps and names in the V9 SPARC life. However, the story suddenly became parallel. Very parallel.

The first UltraSPARC T1 “Niagara” clocked at 1000-1400MHz was the first multi-core SPARC, featured with 4 threads per 8 core. It appeared in 2005. Dubbed as “Coolthreads”, the technology allowed a simpler design and a very good optimization for parallel operations. Its successor, the T2 “Niagara” featured 8 threads per 8 core and was released in 2007.
It’s worth noting that the UltraSPARC line also had “multimedia” instruction set, called VIS. Unlike conventional CPUs (and like mainframe CPUs) SPARC also had a hyperprivileged mode for hypervisor functions. This is nothing new, all mainframe systems required such a feature.

The operating system for SPARCs was called SunOS or Solaris. Despite of the popular belief, these are two different operating systems.
SunOS is based on BSD while Solaris is a System V implementation of UNIX. SUN really made a tremendous effort optimizing its own operating system for the SPARC architecture. Almost all versions of Solaris runs on all SPARC CPUs - with exceptions of course. SparcLITE won’t run the latest Solaris 10 version and will (seemingly) freeze under Solaris 9.

SPARC systems are told to be very stable and robust even for high workloads. The rich features and innovative solutions - like the ZFS filesystem - made it what it is now: industrial leading solution and unlike my previous “guest” CPUs: the present.

The CPU in this chapter is MIPS, which either stands for its founder company or for Microprocessor without Interlocked Pipeline States.

This comes from the clever instruction execution mechanism which uses a well-thought pipeline design which would never stall. In the beginning, it was a 32-bit design, like most RISC designs.

The first commercial version was the R2000. It could be booted in little-endian or big-endian mode and supported four co-processors. One of them was on-chip for exceptions and memory management, and three another one for different uses, like external FPU. It all happened in 1985.

In 1998, the R3000 appeared, with 32K, later 64K L1 cache with cache coherency for SMP designs. An interesting sidenote that R3000 had design flaw in the multiprocessor support but still a lot of R3000 SMP designs were used.
Worth noting that R3000 had many brothers, like R3400, R3500 which were basically R3000 ones with integrated R3010 FPU. R3900 was a SoC, for early handhelds.

The R4000 appeared in 1991. It featured FPU on chip, cache was reduced to 8K and 64-bit support appeared, however a bit buggy. In 1993, R4400 came with 16K cache, bug-free 64-bit support and support for external L2 cache. The R4000 had low-cost versions, such as the R4200, R4300.

The R4600, R4650 and R4700 “Orion” CPUs were designed some ex-MIPS employees and these had larger caches instead of faster clock speed. The remarkable cornerstone, the R5000 had much better performance, thanks to its advanced architecture than the R4000 on the same clock frequency.

The year 1994 brought a superscalar R8000 and a six chip design. It wasn’t in a single package but instead it was spread on a PCB in six units. It also had a huge 4MB L2 cache and impressive floating-point performance at the time. However the integer performance and high price wasn’t really appealing for most customers.

in 1995, the R10000 was released. It was a single chip design, bigger caches and higher clock speed. It was the first with out-of-order execution and was much more preferable than its precedessor, the R8000.

The next ones are the R12000, R14000 and R16000. They have bigger caches and DDR SRAM support in the off-chip cache. The last MIPS came in 2002 and almost nobody expected it. It was a real surprise.

in the beginning, MIPS CPUs were used in Silicon Graphics workstations-and servers. They were legendary of their graphics capabilities. The first hardware-accelerated OpenGL implementation were available on SGI machines and OpenGL is an SGI trademark as well.

SGI developed a proprietary UNIX, called IRIX. It was an unusual one, compared to other Unices, targeted mainly for graphic applications. It is really a desktop UNIX however it has server features. Security-wise it’s advisable not to exploit its possibilities, because it had major flaws in its server softwares.

On the other hand, it is really robust, uses XFS as its own filesystem, distributable and had hardware partitioning support too. It may be still supported but there won’t be any more version of it.

While it’s not likely there’ll be another MIPS CPU design, the MIPS is very alive and kicking: the design is licensable and many successful appliances used, and still use MIPS almost everywhere: game consoles, embedded systems and handhelds, just to name a few.

MIPS is s very clean design, it deserved to be widespread.

This CPU had a lot of influence on the modern CPU design. It wasn’t less but the fastest CPU at its time. It’s no other than the DIGITAL Alpha or DEC Alpha for short.

It is fully clean 64-bit RISC design which is made with speed in mind. For example, it can only read/write from memory, everything else is done in registers. It had 64-bit address/data bus since the beginning.

The Alpha CPU versions are named as EVxx line EV4, EV5 and also had a number, like 21064. EV stands for Extended VAX and according to some, it means Electric Vlasic.
The “21″ stands for 21st century and “64″ stands for the 64-bit nature.

It’s clear that this CPU was made to replace the aging VAX chips and meant to be a very clean design.

At its birth, it was the fastest available CPU on the market, the EV4 or the 21064 had massive floating-point and leading integer performance.

In 1992, the Alpha EV4 21064 was released. It was a superscalar, superpipelined design and outperformed the rival CPUs in price and performance. Thanks to the very careful circuit design, the CPU was able to run at higher clock speeds than the other microatchitecture RISC designs.

The EV5 appeared in 1995, later in 1996 its follower, the EV56 came. Both had the 21164, 21164A number respectively and there was a good reason for the minor version: most programs were unaware of the 64-bit alignment needs and often accessed the memory at byte boundaries. The CPU generated an exception and the handler had to do the math and fetch the non-long aligned byte or word then also had to restart the instruction. The BWX (byte-wide) extension appeared in EV56 was made to avoid such exceptions.

In 1997, a small foresight came, in the name of PC56. It was made for an Alpha motherboard and had the MVI extension. It was a few SIMD instruction which supposed to make multimedia processing faster.

In 1998, the EV6 had all. Had 21264 model number and had BWX, MVI and FIX. FIX was made for moving data between CPU and FPU registers and it was also capable of doing square root with them. This chip introduced out-of-order execution

EV67 21264A was another foresight, it got CIX extension for bit count and finding. It seemed the conventional naming and numbering was on the loose already.

For some reason, the next was called EV68AL 21264B. It had support for “prefetch with modify intent to improve the performance of the first attempt to acquire a lock” and as one of the last models, it wasn’t important to name the feature.

The very last released one came in 2003. It was called EV7/EV7z 21364. Had bigger cache, smaller fabrication process, higher clock speed and bigger caches, but nothing really new, except for one thing: integrated memory controller.

The next models never saw the daylight: EV79 21364A, EV8 21464, EV8 21466. Their eventual fate is unknown but some features suspected to be re-appeared in the AMD Hammer series.

The insteresting thing is, that there was a layer between the CPU and the operating system. It was called PALCode. PAL means Processor Abstraction Layer here. It can be considered as a small kernel which meant to hide the complex CPU operations. It’s worth noting that at least one of the three supported operating systems required a different PALCode: it was Windows NT.

Still, the real operating systems made for this fab CPU was OpenVMS and Digital UNIX. The latter had many names, starting with OSF/1, Digital UNIX and Tru64 at last.

Which may seems strange, this UNIX version was based on the Mach microkernel. Digital was offered the Alpha systems for realtime purposes as well and Mach was well tailored for that. While being 64-bit clean, it was highly POSIX compatible and wasn’t very proprietary design.

It was used widely, thanks to the VMS-derived TruCluster technology High-Availability and High-Performance-Computing tasks was easy. It also had decent OpenGL support and became a favoured graphic workstation and rendering engine as well. Thanks to the scalable architecture, it delivered exceptionally good performance and still does it where it’s used.

A notable difference is its filesystem, AdvFS which made disk management very easy. even with a lot of disks and big storage space it is reliable, redundant and fast. I have never heard Alpha system administrators to complain.
It uses the same CDE user interface as most commercial Unices but has no official alternative solution for that, well except the failover session which is - again - a standard Openlook interface.

The last version at the time of writing is 5.1B. It’s still supported by the current owner.

Goodbye Alpha, we miss you!!! …and thanks for the AMD64 architecture and system bus!

There are/were a few CPUs in the world which had own OSes. They had their own OS, architecture and company. Most of them are already forgotten or socialized to run open source OSes but in their own time, they had maybe a proprietary - OS, tailored just for them.
In the few next entries, I’ll tell a tale about these brave designs which were often market leaders in the industry.

Today’s CPU is called: PA-RISC.

No one knows exactly what PA means. According to some, it stands for Palo Alto, the headquarter of HP, the company who came up with this chip. What is certain however, it’s a RISC design. On the contrary of the popular beliefs, it started its life as a 32-bit chip and just later evolved into a 64-bit design.

Its lifecycle was full of nice and innovative things and version numbers. the PA architecture started with the 1.1 version and later the 1.1a, 1.1b, 1.1c, 1.1d and 2.0 ones came. 2.0 was already a 64-bit CPU with really advanced features.

Based on the good old RISC principles, it gets superscalar in 1992 - which means more than one instruction execution at a time, in a nutshell.

Around the middle of the 90’s, the CPU introduces MAX-1, a multimedia extension for 32-bit SIMD instructions. It supported such operations as parallel add, substract, average, shift right & add.

In 1996, L2 caches and DRAM controller gets integrated into it. What is unusual about caches, that some HPPA chips had large L1 cache, 512K-1.5MB, typically. In the same year, it gets 64-bit, bigger TLB, and another peculiar feature: instruction reordering by hardware. Branch prediction hinting appears in the same year.

In the very same year, MAX-2 64-bit SIMD instruction set appears. Due to its 64-bit nature, more subwords was encoded in a single word and new instructions appeared such as parallel permute.

In 1998, it gets another feature, namely as Speculated Execution which is a kind of branch prediction, but with a few steps ahead. L2 caches gets bigger and bigger and comes off of the CPU.

In 2003, the PA-8800 (Codenamed “Mako”) gets dual-core. It’s essentially two independent CPU on a single die, thus it forms a 2-way SMP set.

The last released CPU model appeared in 2005, the PA-8900. It uses Itanium2 processor bus and is very rare. Almost no reference can be found about it. The HPPA design was officially canned.

The next interesting thing is the operating system, that was made specially for this CPU and architecture. HP-UX which stands for HP’s UNIX is a propritary UNIX, based on BSD and slowly getting System V on the way.

The system is based on a closed-source design, specially tailored for the HP hardware, using its resources as efficiently as possible. Later versions disagree between efficiency and feature-richness, however it’s officially supported, “down to the bone”.

An interesting feature is, it uses VxFS as a built-in file-system and volume manager. Most UNIX versions has it as 3rd party extension. Another difference is the SAM (System Administration Manager) which is capable of doing almost all tasks from a menu-driven interface.

HP-UX major version numbers are 9.00, 10.20, 11.00, 11.11 with a lot other versions. The 10.20 version is notable because of the appearance of 64-bit support and a distinction between workstation and server features. All the other solutions are pretty much UNIX - as we know it. Unices are all different from the inside.

Well, so long PA-RISC, you have a long and interesting history and thanks for the innovations for our future and present CPUs!

Today we will learn about RTOS-es. Lot of people like to use this word “RTOS” but just a few knows what it actually means.

RTOS stands for Real-Time Operating System. If someone knew a little about the concept, would think it means immediate reaction for events. RTOS however is different and more:

RTOS means predictability. A response to an event can be predicted when it will happen. It also means low interrupt latency. We talk about just a few microseconds here. It means real-time scheduling with priority levels. usually it also means small memory footprint.

Another hype is that memory protection is needed, because . The best reason I’ve heard is “malicious programs can corrupt the memory”. Well, since when we forgot how to program? The answer is usually “You can’t do it. Impossible.” Well, VMS, AmigaOS, anyone? Or should I tell, VxWorks, anyone?
Memory protection is good, but overrated.

VXWorks is an RTOS-toolkit which creates VxWorks-based RTOS appliances. According to the FAQ, “no two VxWorks installation are the same”. What is really nice, that it’s used in Mars rovers, various powerplants, routers, base stations, you name it.

While it’s not an RTOS feature, VxWorks is not developed on the same platform where it runs. Development happens in a simulator or a cross-development environment. This is where RTOS makes actually sense. Embedded devices has no CPU cycle to waste and RTOS is just about that.

There are UNIX variants with real-time capabilities however. So why should we bother then? Well, most of them doesn’t even come close. There is, however one very nicely designed RTOS but it’s not UNIX. It’s called QNX.

If the Mars Rovers, - Spirit and Opportunity - still work, I think it’s a good example what good programming and RTOS-es can do.

“

If you know a thing or two about CPUs, you may have seen assembly language. You may have even seen a block diagram how a CPU really works. You’re familiar with the concept of different ISAs, advantages and disadvantages. You’re also probably fascinated about multiprocessing and parallelism.

Well, this thing on the left does right exactly what today computers should: it’s small, it’s very parallel and it’s economic. What does it mean?

- It has 64 cores, each connected independently,
- It has 4 DDR2 controllers, 2 PCIe controllers, 2 10GbE controllers built-in,
- has 64 identical general purpose CPU cores
- each runs at 600 - 900 MHz

It consumes 170-300mW per core which is about…20W if we just round it up. All cores are MIPS compilant ones and the whole chip has a very innovative cache management solution. If you’re interested, there’s more at Tilera’s website.
The picture of the left is a part of a PCIe card, equipped with this chip. It’s a whole computer on its own, it just uses the PCIe bus (and ethernet buses) to communicate. MIPS is a natural choice for general purpose CPUs. It’s free, it’s robust and proven.

This is not a commercial blog, so advertising is up to them. What I want to write, is a few interesting thought about it.

Computing has gone the wrong way a few years ago. Everyone knows that, no matter what beliefs, companies and biased reports tell. All of them have big cooling fans, pathetic performance sometimes and very high clock speeds, compared to the effective performance what they really provide. On the other hand, for parallel processing most of them are useless - or at least close to. What as initially a good idea (and had some pretty good realizations!) now is just a 7th skin off the fox.

This one however, represents a competely different approach. It’s not a new idea, CRAY machines looked like the same, many years ago. That’s not your average desktop pc, but needed a special room with airconditioning and liquid-cooling. Those were real supercomputers for massively parallel applications.
Parallelism is always a way to do things. Since the appearance of multitasking everyone wanted to do more things at once. Multitasking is really just an illusion, but a good one. By switching the CPU between tasks (and save its states between them) it really appears to be doing multiple tasks at once. However the tradeoff is there: context-switching requires time, and each task has its timeslice which is completely owns the CPU. Definitely, it’s not parallel and by that I mean someone who only uses his/her pc to read e-mails, maybe watch a few movies and browse the web. It’s fair enough for that.

However, for this purpose, a much smaller CPU would be enough if the operating system is implemented properly.
Of course, whenever a more demanding task appears, the system runs off of resources very easily. Now, imagine that you have 64 of them! The term “scalability” is really true for this chip. If there’s no need for big power, a few small cpu can do the trick. If there’s a need, they add their power together to outperform the One Big CPU.

….did I mention that it’s also “cool”?

I am all right, don’t worry. It’s just that I recently purchased a Nintendo Wii console. There also was a funny advert for Firefox. This two is not related, except the pronounciation of the name “Wii” . The console itself is a laugh in a positive way.

The first impression is a very flexible and slick user interface, WLAN and Bluetooth capability, this is how the system utilizes its internet access and handles the controls. Yeah right, no strings attached. There is a sensor bar too which should be placed either above or below the TV set, to sense the position of the wiimote. It’s look like what you can see on the left. It has one more button on it’s back which looks like a trigger and often used as such.

The aching elbows and arms are the first side effect of playing with a Wii. It really makes you work! This is a very innovative step in my eyes, sitting in front of a TV with a controller is nice but it even makes you feel you’re actually there.

I have tried three games with it and so far Red Steel is the one that made me work a bit harder. It involves precise aiming and wielding, and while it may sound easy, it requires concentration. You can’t just wave around, the aiming really needs to be sharp and fighting with a sword requires timing and well executed moves let alone the fact that this thing is very sensitive. If your hands tremble, you will see it, if you can’t hold it on target, you’ll see it and often suffer from the consequences. No wonder someone wrote that “it’s about 10 minutes of intensive hand movement you can expect from geeks.” There’s more though. The other controller is connected to the wiimote is the nunchuk controller. It’s a thumb joystick with a pistol-like grip and two buttons. It also has a acceleration sensor inside so it can’t sense position but it can sense horizontal and vertical movements. Often used for movments which are simple, such as gun reloading, switch toggling and so on.

The icing on the cake is the full backward compatibility with GameCube titles. Unfortunately it requires a controller and a memory card from a real GameCube but for some reason, I happen to have one. All of my GC titles actually work! Can’t really tell if they’re faster or not. They should be a bit, at least.

The whole Wii is built around “channels” which are made for different purposes. The “game channel” is the inserted DVD, for example. The “weather forecast” is some weather information, pulled form the web via wireless. So is the “News channel” and so on. There’s a shop channel too, where I could buy games for Wii points but haven’t tried it yet.

So far, it’s fun. And my arms and shoulders are getting used to it.

My new toy has arrived, lately. It’s the same Pegasos machine I had once but had to give it back, because moving to UK.
Fortunately, a good friend of mine posted the whole machine to me so I can have a full fledged Amiga clone at home. Some may ask, why is it good to have a clone of an outdated (old) machine which is not fast neither modern. Well, one who never saw/owned an Amiga will never know and never understand but this puppy has a few tricks up in its sleeve.

The whole concept if Amiga systems was based on the user. The user and nobody else. It’s a single user machine not fo anyone else, not for thousands of users but for one. It’s very friendly and easy to develop for. The classic ones were based on 68K processors and custom chipsets which were groundbreaking at that time. It also had stereo sound with four channels with 8-bit 22050KHz at max. With tricks It could do 14-bit 44100KHz and unlimited channels with a faster CPU.

The Pegasos is a new concept with a proprietary microkernel based OS, called MorphOS. It runs a single process, called a\box. Inside the a\box there is a full AmigaOS environment with ful API compatibility (99% according to the developers) and even a 68K emulator! It also features PowerUP and WarpOS compatibility which was made for the last PPC-based classic Amiga models.

What I will do with it will be mainly development. Porting those programs that are available for everything else but not for MorphOS. It has a nearly complete POSIX API but a lot of things are simply not available or different. For example, AmigaOS has no virtual memory neither paged memory. Therefor the whole process model is also different. It has however a very low scheduler latency and a good Amiga-legacy shared library system with a nice and friendly API.

Because of the missing custom chips, it can’t run classic Amiga games/demos directly (not all of them) but can use modern sound cards and some of the ATI cards. This one has a Radeon7000 inside. Yes, 3D is also supported.

So far my porting activities were to establish a good development enviroment and to try to port a torrent client. Still a few things are missing. Need a decent pthreads port or a replacement and some newer libc functions.

Well, this is what porting is about…

No, these things aren’t competely related. And yet, they are.

What I am trying to do these days is, to compile a working Darwin system. Probably I should call it Mac OS X, that might sound familiar. It’s the open source foundation that makes OS X tick. It’s a full featured operating system itself, from ground up, based of open source elements.

So far I’ve succeeded to compile parts of its kernel but it needs the newest GCC (of its own) to compile sucessfully. This is what I get (on the picture) as for now: errors, lots of them. This seems to be meaningful for Apple engineers, but not for open source developers like me.

I will receive an AlphaPC this week, which is an evaluation motherboard, but based on the Alpha processor. This is a rather “toss it away” machine for others but a real gem for me. Thanks to Alphamike for sending it to me!

Pegasos is the same kind of breed. I’ll receive it this week probably. This time I’ll continue my efforts to help the Pegasos scene. This is an older, PowerPC based machine (G3/600 to be exact) which seems to be slow, but not when it’s runing MorphOS!

These facts - according to a friend of mine - entitles me to be called as a “cube”. Here’s what it’s about:

cube [ kocka ] (noun)

“A person who knows more about computers than the average so he/she either marked as a weirdo or often threatened with pejorative expressions, such as “menjél inkább kockulni”, “szórakozz a gépeiddel inkabb”, etc.. Ironically, this is the person who is called when some IT-related problem occurs. He/she is warmly welcome then.”

While I didn’t care about it in the past, now I usually tell them: “Proud to be a []!” and if they continue pestering me, they can fsck off….