Increase size Decrease size Revert styles to default
Search

odd_parity

Pairing in progress...

Show the panel
ISO - let's fast-track anything!

Written by Radoslav Dejanović, on 20-05-2008 00:48

Views : 7502    

Favoured : 238

Published in : , English language


Few days ago I have been told that there's another fast-tracking process going on in ISO.
This time, it isn't really about computers or office formats, but the story is interesting never the less;
it's about ISO IEC DIS 14908 - Open Data Communication in Building Automation, Controls
and Building Management — Control Network Protocol.

You see, modern building have changed since the Roman time. Ok, except the concrete that Romans invented is of much better quality than what is used today. Except for being built to last, Roman buildings didn't have those nice devices that would open a garage door for you, open (and operate) an elevator, turn lights on and off... Now, if you say X10, you're on the right track.

So, what is the problem with 14908? It's just another standard for having intelligent devices in your walls, so what is a big deal?
I have looked at it, and it reminds me of that OOXML vs ODF adventure of ISO. You see, there are already standards that cover everything that this proposal offers. There's, for example, EIB, which is prominently German protocol. It's a little bit older but it is what is considered an open standard. There's a spec, so you can go and build any part of the building automation - be it a controller, an actuator, a sensor, anything. Just keep it within the specification.

14908 looks like it isn't really an open standard. It's patent encumbered, for a beginning. That's royalties imposed on manufacturers and customers, and probably there is going to be a manufacturer that has exclusive rights to produce a piece of hardware that you have to buy if you want this network to operate.

Given, this new standard does something better than, for example, EIB: while EIB talk about 9600bps communication speed, and a maximum of 65536 connected devices, and using RS232 to communicate with your PC, 14908 is giving us a nice view of wonderful TCP/IP world.

Well, almost. You see, I am not an expert for embedded electronics, nor building automation. I am neither an expert on computer networking and TCP/IP stack, but I do think that I might say that I do know at least *something* about that technology. So I have read the part of 14908 proposal that talks about networking. It looks that the main idea of new proposal is to get rid of separate data buses that is mainly used in older standards for data transmission between the devices, and to use - computer network cabling, the humble UTP.

Now, let us think. Is the cost of cabling separate twisted pair for building automation really that bad? One can probably save a lot of money by using the same UTP-based cabling for computer network and building automation... but, would you really like that?

I might be very wrong here, and it might turn out that the authors never really considered mixing computer network with CNP network, in which case it would not be such a disaster. But, what if I'm right? Just to be sure that I'm not talking complete nonsense here, I have asked few of my friends who I consider quite good with TCP/IP to give me feedback on this.

First of all, those devices use a subset of TCP/IP - and there's no rule that the full stack should be implemented. If you were a network administrator, would you allow such devices that are completely out of your control to share your network?
Indeed, you could separate them into VLAN-s, but that's extra effort and taking any care of building automation devices shouldn't be a network administrators problem.

Let's see what is inside. The preferred communication packet is UDP, which is connection-less and does not provide any means to be sure that your datagram has reached the destination. It's quite Ok for sending rapid stream of data where you don't really care if some of it gets lost (think VoIP or computer games). However, the authors of 14908 talk about quasi real time performance (something you want to have if you control the elevator speed and position, for example, or security doors) and data consistency! A quick reminder - TCP packet can achieve quasi real time performance and has means to ensure data consistency.

TCP is an option, named primarily for device configuration. And to ensure that UDP packets could be sent over different routes and later be arranged in correct order, devices should append a sequence number onto each UDP packet, so that the receiver can sort them out. Again, something that TCP already has.

This thing doesn't work trough NAT. If you have two buildings, they have to have clean route and they'd better not be using NAT, or there will be no CNP/IP communication between them. Since many modern computer networks use NAT these days, this could really be a big issue for network administrator.

There's "CNP Wants All Broadcasts" flag that can be turned on and off. I can't think of a reason why a device should not listen to broadcasts, which are supposed to be something that carry some important information. Oh, there is one good reason - if you have cheap device with measly CPU and tiny RAM of 256bytes, you don't want to spend time computing broadcasts. But still, this looks like a bad design.

And, while we're at it, the proposal talks about stale packet detection. In real time operations it is of vital importance to know when the packet you received is too old to reliably reflect the real situation - elevator speed and position data is irrelevant if it is more than one second or so old! Now, the paper states that devices can switch off that stale packet detection if it is not necessary - it looks like another compromise for devices with low computing power.

Stale packet detection, by the way, please read this (taken from 14908):

"A packet is considered to the stale if the time it takes for the packet to be transported from the sender to a receiver in an IP channel is greater than the channel timeout period (CTP). The CTP is a period of time that represents a reasonable upper bound on the time it takes a packet to go from a sender to a receiver on the IP channel. This European Standard does not cover how the channel timeout period is determined. Suffice it to say that it has units of milliseconds and is known by each of the CNP/IP devices in the IP channel."

Suffice it to say that this is very, very vague definition and still trying to go trough fast-track. But, for the argument's sake, let's say that this is acceptable for a real time application - you do want to know how old is your packet, and we shouldn't be really grumpy about different devices having different thresholds for "this packet is too old", rather than defining one single value for all devices on the network.

But, look at this:

"In the case of CNP/IP to CNP/IP routers the packets are re-stamped with the most recent time before
being forwarded onto the next IP channel."

What this means is that, if you have four network segments: A->B->C->D, if your packet has to jump from A to B to C to D, at each hop it's being re-stamped with new time. Well, in case you really must know the exact time when that data entered the network (as is case with real time systems), by doing re-stamping you will never be sure that your data is not too old to be considered relevant.

That is about time-stamping UDP packets, so you know the time. Everything is kept in check using NTP protocol, which is great for local segment, and even for distributed networks as long as all time servers are in sync, but:

"Since the time server is the common basis for time on the network the device may continue forwarding packets only as long as it is reasonably sure that it is within the margin of error of the time server before it went off line."

I'd say that in case of NTP server going down, entire building would stop in two hours after that, since all devices will be out of sync, and as the error accumulates, they will cease sending packets one by one. Lights out. Doors won't open. Security systems would shut down... pretty scary, isn't it?

Here's another gem:

"Newer or older versions of this data may be determined with a resolution of 1 second by looking at this field." - which means that resolution to distinguish what data is preceding what data has a resolution of one second, which is ages in real time operations. I think I didn't get that correct?!?!

And, there are definitely things that must be clarified, because they are simply not true:

"The UDP payload length of approximately 548 bytes causes restrictions in the membership of channels
and causes other problems when nodes are considered." I'm sorry, but UDP can be up to 65507 bytes long, and header is just a tiny part of it...

"ACK messages are not sent on TCP connections;" - huh?!?!

"retransmissions are not performed on TCP connections;" - huh again?

This probably is about CNP not having to send its own ACK-s, not stating that TCP doesn't do ACK's or retransmissions. I find this quite confusing.

Regarding ACK-s:

"ACKs are not retransmitted, but the state change in a device is always such that receipt of a
duplicate previous message in the protocol causes no state change and causes retransmission of
the appropriate ACK." - are they or are they not retransmitted?

Then this: "segment packets are never used. Packets, regardless of size, are sent in their entirety"... this seem to be in collision with another sentence from that protocol: "Certain CNP/IP messages may cross a UDP datagram boundary. In such cases a special segmentation protocol is defined which can be used to facilitate this."
It's quite conflicting. Or the reason might be that this is done just to implement a special segmentation protocol that does the same thing normal TCP/IP implementation does, but this one is special because there's tiny patent attached to it?

You can do data bunching, as well. This means, if there's more room in an UDP packet that is for no apparent reason confined to 548 bytes, you can squeeze two or more of data payload segments into it. Just so that you know.

Speaking of vague, there's interesting method how a device can check whether the other device support TCP:

"The only way for the device to determine whether the configuration server supports TCP is to have a
connection succeed. This mechanism assumes that a node that does not support TCP cannot respond
with Connection Refused."

Isn't that great? You could send an UDP packet asking other side whether they support TCP, but no - you have to wait for a freakin' timeout to find that out? And, what if there's a firewall or a smart router in between, the one that can silently drop packets? Who's going to debug that? Network administrator? Electrician?

Wondering about DoS attacks?

"If the number of simultaneous connections supported by a server is smaller than the number of devices
on the channel, devices might receive connection refused messages from the server when trying to
connect. Such responses should indicate that there are insufficient resources on the server. In this case
they try again after a suitable amount of time, or elect to use UDP."

If a device is too busy to answer, there's no point in switching to UDP packets, for two reasons: that device just can't answer packets so it is not going to answer those UDP packets, and since first device can't open a connection to the other device that can't know what is going on, the other device will assume that the first device can't talk TCP (see four paragraphs above) and happily send a stream of UDP datagrams to poor DoS-ed bastard, causing even more mayhem on the network.

I like this one:

"Security in CNP/IP devices is optional."

And that one, too:

"The level of security described in this sub-clause is authentication. Messages sent using the scheme
described here are authenticated as coming from a trusted source. Information inside the messages is
not encrypted and not hidden from inspection."

We're talking about devices that might share your computer network, a place known for peaceful coexistence of many people who would never do anything bad... Like sniff the network, then craft the packets so your elevator goes trough the roof, or stops between the floors. Or start going up and down and up and down...

There's more of that, but those are the most interesting parts. People I have talked with about this did not completely agree on what might be the possible reason for such vague definitions. The closest we've got is that the reason might be the cheap devices with slow CPU and just handful of bytes of RAM, so the protocol is tailored to allow them most efficient usage of network. That might be fine for them, but I certainly wouldn't like to have any of those on a computer network I am responsible for...

There are some patents inside, you know, thirteen of them. Most expire in 2008., some expire in 2011. and 2012.
A conspiracy theorist would say that somebody is trying to push that trough ISO as quickly as possible to get what is left of the royalties...


So, what makes this ISO IEC DIS 14908 inappropriate candidate for fast-track process?

1. There already are standards and this one doesn't bring nothing really new
2. definitions are vague and there seem to be a lot of things that should be clarified BEFORE this could become an ISO standard.
3. There are patents inside; this does not disqualify a proposal, but it certainly is not an open standard, so should be considered sub-par to open standards that have no patent encumbrance.

At the end of the day, it might be that I didn't understand the proposal and most if not all of my objections are incorrect (and I'm making fool of myself). However, what I do believe is that this paper is really vague and open to interpretation, not something that we would like to be a standard in a state like that. It's Ok if 14908 goes trough the full procedure of standardization, as that would weed out any vague or incorrect things. Going trough fast track, however, it just looks too similar to OOXML story - where largely unfinished standard rockets trough ISO because there's a company that might have some revenue lost if the proposal has to go trough tedious standard procedure.

ISO really seem ready to fast track anything these days. We should watch more closely every fast track process, or else those people from ISO might one day go to their offices and end up being stuck in elevator going up and down and up and down...

 

(update) Due to the popular demand, here's the clarification of "prominently German EIB": EIB is a protocol devised by EIBA, association of many organizations - and most of them are from Germany. No more, no less.

 

Here's the list of patents in 14908 as well:

 

U.S. Patent No. 4,918,690                          Network and Intelligent Cell for Providing Sensing, Bi-Directional  Communications and Control
U.S. Patent No. 4,941,143                          Protocol for Network Having a Plurality of Intelligent Cells
U.S. Patent No. 4,955,018                          Protocol for Network Having a Plurality of Intelligent Cells
U.S. Patent No. 4,969,147                          Network and Intelligent Cell for Providing Sensing, Bi-Directional  Communications and Control
U.S. Patent No. 5,182,746                          Transceiver Interface
U.S. Patent No. 5,297,143                          Network Communication Protocol Including a Reliable Multi-Tasking Technique
U.S. Patent No. 5,319,641                          Multiaccess Carrier Sensing Network Communication Protocol with Priority Messages
U.S. Patent No. 5,420,572                          Configuration Device for Use in a Networked Communication System
U.S. Patent No. 5,500,852                          Method and Apparatus for Network Variable Aliasing
U.S. Patent No. 5,513,324                          Method and Apparatus Using Network Variables in a Multi-Node Network
U.S. Patent No. 5,519,878                          Method and Apparatus for Network Node Identification
U.S. Patent No. 5,856,972                          Duplicate Message Detection Method and Apparatus
U.S. Patent No. 5,737,529                          Networked Variables

 

 


User comments (1) Quote this article in website Favoured Print Send to friend Save this to del.icio.us
Last Updated ( Tuesday, 20 May 2008 )
 
How to do some basic overclocking of your PC

Written by Radoslav Dejanović, on 02-05-2008 00:46

Views : 7814    

Favoured : 250

Published in : , English language


Overclocking, or how to squeeze a juice out of dry wood - is a compromise between getting better performances for your money and expected life of the components.
I used to be really interested in overclocking, back at the time when the difference between 333 and 466MHz really saved couple of minutes of your task, be it 3D rendering or compiling a kernel. You could, with some effort, get 40% increase in performance, and that was really worth it. Even if that meant having to draw conduction lines between pins with soft graphite pen to unlock the multiplier on your AMD Athlon (and THAT was the funniest thing I have ever done to overclock the CPU!).

Now, that was back in the old days. Today, it is still fun, and can get really extreme if you happen to have some liquid hydrogen nearby, but I gave up on any extreme overclocking. Not because of the fear that I am going to shorten my CPU lifetime (from 20 years down to, say, 10?) or burn my hands with liquid nitrogen, but because I lost the interest for extreme overclocking, and it has become more extensive, with much more variables to take into account, while not providing so great advantage over unmodified components.

Then I bought myself this Intel Q9450 and Asus P5E motherboard. I tought I might want to overclock it, so just in case I bought Kingston DDR2-800 RAM designed for overclocking. Hey, it's cheap, so I bought whole 8GB of it.

Then I had a crash with my Linux disk. Happily recovering from that, I just couldn't resist the temptation. Q9450 is four-core CPU running at 2.66GHz, with 12MB L2 cache. A little beast, I tell you. But, I tought, wouldn't it be nice to round that frequency to something higher, like 3GHz?

Now, before I tell you what I did, you have to keep in mind two things:

1. overclocking is not a child's play, and you can damage your hardware. It is not a joke, you shouldn't do that if you are unsure of what you're doing;

2. to succesfully overclock, you have to have hardware that support it; most modern MBO-s and CPU-s do, but you will want to get some that are known to be overclocking-friendly/-easy.

Third thing: you should keep in mind is that you are doing it at your own risk, and what I have done might not work for you, it might even damage your computer and void your waranty, so please, don't do this - and if you do, and something bad happen, don't tell it's my fault. You have been warned.

Now, let's see how to make some slight overclocking; I'll refer to my CPU and my MBO (Intel Q9450 and Asus P5E (green)).

Probably the easiest way to overclock your computer is to fiddle with Front Side Bus (FSB) frequency. This thingie could be considered as sort of central clock for the entire computer (don't take this literally), and increasing FSB will increase the speed of pretty much everything else except your disk drives.
My Q9450 run on FSB of 333MHz. It has a multiplier of 8, thus giving the CPU speed of FSB x multiplier = 2664 MHz (2.6GHz).
In the old times of Pentiums, almost every CPU model had "unlocked" multiplier, meaning that you could change that eight into nine, or ten - and get faster CPU while not increasing the overall speed of your other components. Today this is not a case, and my CPU can't change multiplier. Some CPUs can, though, such as Extreme edition of Intel CPUs, but they have a premium price that just isn't worth it. However, for the middle range, you're stuck with fixed multiplier.

So, what did I do? I have increased FSB to 425MHz (as I have read on the Intertubes that safe limit is about 427MHz), and - whoa! - after the reboot, my Q9450 got a kick of 3.4GHz!! Not bad, is it?

However, my other goal was to keep my system cool, and overclocking should heat the processor up to 50 degrees Celsius. The components can get hotter than that without much problem, but I like it cool.

The other problem was that my helpful Asus P5N motherboard has really nice overclocking options, where you can increase FSB manually, and let the motherboard take care of the rest. This is just great if you aren't an extreme overclocker, but I found out that my nice MBO raised Vcore voltage too much, to 1.4V, a value I am not comfortable with.
You see, Vcore voltage is the power supply voltage supplied to the CPU, and there's just so much of it. If you overclock your CPU, you might have to increase that value because overclocked CPU has bigger demand on power. Starting voltage for Q9450 is 1.2V, and the tolerance should be about 10%, which means that the safe limit would be 1.3V, and 1.4V is still good, as it gives enough power, but increasing voltage makes your CPU hotter, which then makes CPU life expectancy shorter. Theoretically, you can go up to 1.7V, if you wish your computer to burst in flames... (that won't happen, but it sounds scary).
Having a good cooler is paramount, so get yourself a decent cooler. I like them with big fans, as bigger fans are quieter.
To cut a long story short, I have manually set my Vcore to 1.25V, and left everything else on auto. That was too little for FSB clock of 425MHz - the system crashed under load.
I lovered FSB a little bit - to 420MHz - to get still impressive 3.37GHz out of my CPU. And at the beginning all I was asking for was round 3000MHz...
The system proved stable with FSB 420MHz and 1.25V Vcore. The bonus effect is that my RAM chips, certified for DDR2-800, became DDR2-1009 :-)
If you remember, increasing FSB is going to speed up pretty much everything else in your computer...

To check the improvement, I fired up simple glxgears application. This does not do much, drawing some spinning gears in the window, but I like it as a quick and not too reliable benchmark. The result is satisfactory: before overclocking, my computer did about 20.000fps, and after it went ten percent up, to 22.000fps. The temperature did increase some degrees and now the CPU is over 40 degrees Celsius while not doing much, up to 50 while under heavy stress. I think this is acceptable.

I don't recommend anyone to overclock the machine, as there's always a chance that something could go wrong. If you, however, think that taking moderate risk is worth 22% increase in CPU speed (and about 10% in overall performance of your computer), you might find simple FSB increase a relatively safe and easy option. Overclocking-friendly motherboards are of great help in the process. But, keep in mind - if you fry something, don't blame me!


Be first to comment this article Quote this article in website Favoured Print Send to friend Save this to del.icio.us
Last Updated ( Friday, 02 May 2008 )
 
Interoperability (and a word about CLUC 2008)

Written by Radoslav Dejanović, on 27-04-2008 21:58

Views : 6547    

Favoured : 254

Published in : , English language


I had the honor to write an editorial for Privredni Vjesnik, a business magazine with quite high circulation (100.000) for such a small country as Croatia (4.5 mil. people). I was asked to write a short article about interoperability.

 

Given the typical audience (upper management), I did not delve into peculiarities of IT interoperability, but instead used an analogy with the automotive industry to present the possibilities and impossibility of full interoperability. I went as far as to ask readers whether it would be nice to have a car made by one manufacturer that can have its parts replaced with better/cheaper parts from another model from another car manufacturer, and still maintain the integrity of the car as a vehicle, to conclude that yes, that would be terrific for the consumer, but the automotive industry is never going to do that; then, I've moved that analogy to IT industry, where there are many systems that should, and could, and it wouldn't be too hard or too expensive to make - talk to each other and exchange information, regardless of who made what software or hardware... just to conclude that IT industry is very much like the automotive industry, and where should be interoperability, it is being avoided by manufacturers for exactly the same reason (money, vendor lock-in...) - and that, at the end, the victim is the end user.

 

Few days later, I vent on to help my school mate from primary school migrate his e-mail messages from PC to Macintosh. If I had done that before I wrote the editorial, it would be really, really different - I would omit analogies to talk directly of one example where interoperability is being screwed up by the same software company that makes both products!

 

Could you guess what company's that? The one that makes e-mail reader for PC that can not exchange mail messages with another reader made by the same company for Mac OS X?

 

Would you be surprised if I tell you that the company is - Microsoft?!?!

 

I was surprised, honestly. The PC software is Outlook, part of MS Office for PC, and the companion is Entourage, outlookish mail reader and part of - can you guess it? - MS Office for Mac!

I mean, Ok - those two are different programs, at least as long as their names matter. The fact is that users see Entourage as Outlook for Macintosh (and it does serve that very purpose on Mac version of MS Office). I would never, ever, think that there might be a problem moving mail messages from Outlook to Entourage. But it is impossible without the third party application! How cool is that? Interoperability, you ugly word, you shall not exist! Curse you! And, curse everyone who dare to move from PC to Macintosh! No e-mail for them, naughty people who dare to move from Windows to OS X! No cookies for them!

 

There it is - If I knew it, I would happily write about that experience as a prime example that interoperability is something that is not that hard to achieve in software world, but is often thwarted by greedy interests.

I can't stress enough how big this annoyance could be for a business user.

If you happen to run into this issue as well, there's quite simple and massively ironic fix: you'll have to use some FLOSS software!

The solution is acutally quite simple: Install Mozilla Thunderbird on your PC, and let it import MS Outlook mail. Once that is done, export mail from Thunderbird in MBOX format - just transfer your mail files from your profile to some folder on your Macintosh. As Entourage can import MBOX messages, you'll end up importing that, and probably do some manual filtering of imported messages. Or, use the script provided here: www.entourage.mvps.org/accounts/thunderbird.htm.

While you're waiting for a piece of FLOSS software to import your mail from Outlook, it would be great time to think about using MS Outlook and MS Entourage, and probably ditching them both for a solution that trully is interoperable - Thunderbird. Unless you simply must use Outlook or Entourage, Thunderbird would be great replacement - and if you ever have to move your mail around different architectures, as long as there's Thunderbird for it (Windows, Linux, Mac OS, BSD are supported, and since it is FLOSS it can theoretically be ported to any platform imaginable - notice the word "theoretically", please :-), your data will happily follow you.

 

My bitter conclusion would be this: how on Earth could a company that failed big time to provide interoperability between two almost siblings of their flagship product that run on Windows and OS X platform... how could they persuade ISO to fast-track their proposal as a standard that should ensure interoperability between not-so-mall number of different applications made by different manufacturers?!?!

 

 

 

 

Now, just a few words about DORS/CLUC 2008: for the majority of you who don't know, this is the biggest and probably the geekiest FLOSS conference in Croatia. It's been arounud for 15 years now (!) and over time has attracted many great speakers and number of participants, covering areas of Open Systems, these days mainly Linux and BSD. This years event was, IMHO, one of the most successful regarding speakiers and quality of the event.

 

There were some really interesting people: Alan Cox, Matchtelt Garrels, Andrew Shitow and Marino Marcich (just to name some of foreign speakers), and number of local gurus as well. What is really new is that this year Microsoft has participated as well. Nobody was sure whether they are going to talk or not, as it seems there were some small (political) issues on both sides, but at the end they did participate, and I find this really Ok. They were talking about their licensing models that are "certified" as free software licenses, or close to that. Nothing really new here, but it was quite good ice-breaker and a ground for more serious participation on CLUC 2009. The auditorium was at the beginning a little bit sceptical, but as the ice melted the fun kicked in, and there were a number of questions from the audience. Ratko Mutavdžić (MS speaker) held the ground quite Ok, despite sometimes not so easy questions, and he definitely survived the very direct and not at all diplomatic questions from Toni Prug (who previously held also a good speech about FLOSS in the world of Capitalism), who at one point concluded that "Microsoft is a cancer on the body of Capitalism, and that cancer should be cut off" - quite a strong opinion, but it seems that as soon as somebody pulls Immanuel Kant into conversation, "diskurs" moves to heavyweight category...

 

Just as I said, this year's it really was fun. :) I hope to see more of that next year. :-D

 

 

 

 

 


Be first to comment this article Quote this article in website Favoured Print Send to friend Save this to del.icio.us
Last Updated ( Sunday, 27 April 2008 )
 
Thou shalt not change hardware

Written by Radoslav Dejanović, on 20-04-2008 22:46

Views : 7059    

Favoured : 239

Published in : , English language


The reason I haven't posted the story about DORS/CLUC 2008 already is the fact that I dared to install new motherboard (Asus P5e) and new CPU (Q9450). Oh, and a new graphics card - an Asus 8800GTS TOP.

I was a little bit sceptical about how my Windows partition would survive such a drastic change, but none the less, the reinstallation was long overdue.

 

So I did it. At first, everything seemed well. Then, it happened. I couldn't find my Linux partitions. Everything has turned into a really, really big FAT12 partition on that drive! Luckily, there's an angel named Michail Brzitwa, who wrote a thing named gpart - a small utility that will take a guess at what your damaged partition table used to look like. In my case, the guess was right - and as soon as I have recreated my partitions using fdisk and data provided for me by gpart, the icons on desktop popped up! I've checked the consistency, and everything is well.

That left me with a discovery that my drive is not in good shape - a clicking sound emanating from it is generally not a good omen. So I rushed to the store (and THIS is one of the reasons that at least some stores should be open at Sunday), bought a nice 400GB drive for my new Linux partitions, removed the old drive, installed the new one, and in a bold move I took pre-release of Ubuntu 8.04. It's Ok. It does work. I have had some issues with new nVidia card with Ubuntu 7.10 (namely, a big drop in performance over my old 7900), but now it runs faster than my old card - as it should be.

Windows XP did not survive the change, however, and reinstall failed as well. It seems my computer is too new for XP without an SP. I'm not going to buy Vista, though - not for those few games I play on Windows (as that is main reason I keep Microsoft on my computer).

After the initial setup was done, I used KamaConnect USB to SATA/PATA adapter to connect my old drive with my conputer, and with a help from trusty Midnight Commander, transferred my old home to my new home, did some chmod and chown, and voila - my old home partition on shiny new (and somewhat faster) disk drive!

 

So, to cut the long story short:

1. Do backup! And don't forget about it!

2. If you hear clicking sounds from your computer, brace yourself for possible data damage (and get a new disk ASAP).

3. If you get into trouble, there are some nice people out there, who wrote nice programs that can help you a lot.

4. Windows XP doesn't like new hardware. But it is getting obsolete. For some people it's XP, for some people it's Microsoft altogether.

 


Be first to comment this article Quote this article in website Favoured Print Send to friend Save this to del.icio.us
Last Updated ( Sunday, 20 April 2008 )
 
ODF accepted as Croatian national standard

Written by Radoslav Dejanović, on 01-04-2008 21:17

Views : 10199    

Favoured : 301

Published in : , English language


Today, after a four hour meeting, Croatian CSI accepted ODF as a national standard.

I have rather few and incomplete information from the meeting (formal press release will be made by CSI in a few days, I hope), but as it seems, there were mostly political and not much technical objections regarding ODF (that were risen by Microsoft earlier on), but at the end of the day ODF was accepted. It is worth noting that Microsoft requested that their statement pro ODF be officialy noted. That is a fair move from Microsoft, as they declared previously that they are for standards in general, even if we remember that it was their objections that caused the delay.

It is important to say here that having ODF as national standard does not force anyone to use it, not even government bodies. However, a victory here is that this really did open a door for users who do not have MS Office to exchange documents with government bodies, as they will be using national standard from now on, and should not be denied if they send their document in ODF format. In many previous cases, offices would accept only .doc files, as it was "de facto" standard, and there was no national standard at all. Well, now we have one!

Being able to exchange documents using ODF is quite important for me - I have a freedom of choice (and the rest of Croatia, for that matter). That is always a good thing. :-)

 

P.S. And I do like the fact that my country is going to get some positive press coverage for doing the right thing.

P.P.S. No, this is NOT April joke! :-)


User comments (3) Quote this article in website Favoured Print Send to friend Save this to del.icio.us
Last Updated ( Wednesday, 02 April 2008 )
 
<< Start < Prev 1 2 3 4 5 6 7 8 9 10 Next > End >>

Results 31 - 36 of 73