There's been a long-running argument about whether making eBooks freely available without DRM or anything like that helps or hurts sales of physical copies of the book. The DRM proponents have usually argued that the people saying freely-available eBooks help sales are depending entirely on anecdotes that don't prove anything. Well, end of that argument. A pair of graduate students at the University of Michigan did a detailed study of 41 titles that were released as eBooks, looking at their sales figures pre- and post-eBook release. In most cases, an eBook release meant increased post-release sales of the books. The exception was Tor's release, which dramatically demonstrates the problems with restrictive eBook releases. Tor made the eBook versions available for only one week, required registration before you could download and generally made it annoying to get the eBook version. This group of books suffered a significant drop in sales, while the other 3 groups studied showed significant increases in sales.
Publishers take note.
Friday, March 5, 2010
Friday, October 23, 2009
SCO v. world in a nutshell
To borrow from Darl's favorite cattle-rustler metaphor:
Darl had some cows on his ranch. He noticed that some of the cows on other people's ranches had the same brand as his, so he decided to get a posse together to go after those cattle rustlers who'd stolen his cows.
Then it was discovered that the brand wasn't Darl's, it was the brand of a completely different ranch that'd sold cows to just about everybody in the valley. And worse, as it turns out Darl hadn't even bought those cows, some of his own hands had found them wandering on his land and put them in with the rest of the herd. So now not only are the other ranchers mad at Darl for accusing them of stealing cattle when they hadn't, but some of them are accusing Darl of being the cattle thief.
But poor Darl's still positive that somebody somewhere had to have stolen some cows that should've belonged to Darl if he could've afforded to buy them.
Darl had some cows on his ranch. He noticed that some of the cows on other people's ranches had the same brand as his, so he decided to get a posse together to go after those cattle rustlers who'd stolen his cows.
Then it was discovered that the brand wasn't Darl's, it was the brand of a completely different ranch that'd sold cows to just about everybody in the valley. And worse, as it turns out Darl hadn't even bought those cows, some of his own hands had found them wandering on his land and put them in with the rest of the herd. So now not only are the other ranchers mad at Darl for accusing them of stealing cattle when they hadn't, but some of them are accusing Darl of being the cattle thief.
But poor Darl's still positive that somebody somewhere had to have stolen some cows that should've belonged to Darl if he could've afforded to buy them.
Labels:
copyright,
intellectual property,
law,
sco,
unix
Monday, October 19, 2009
Sidekick data lossage
You know that big T-Mobile Sidekick data loss incident last week? Well, it seems a source is pointing at the potential cause. Long and short: the service did in fact have a backup, and did in fact start to do a backup before the migration. But they only have space on the SAN for 1 backup copy, and the backup process takes 6 days to run. So part-way through the backup the Microsoft manager in charge ordered them to abort the backup and start the migration, since the storage vendor had assured them a backup wouldn't be needed. Naturally Murphy stuck his nose in mid-way through the migration.
With Microsoft's track record for bad management decisions, this sounds plausible. And in a case like this you can't blame the technology. No tech will save you from this sort of deliberate stupidity.
I'd also note that the whole incident should be a warning to everyone: you need your own backups of your data. It doesn't matter what the contract says, failures can still happen and you need to be able to recover from them.
With Microsoft's track record for bad management decisions, this sounds plausible. And in a case like this you can't blame the technology. No tech will save you from this sort of deliberate stupidity.
I'd also note that the whole incident should be a warning to everyone: you need your own backups of your data. It doesn't matter what the contract says, failures can still happen and you need to be able to recover from them.
Labels:
cloud computing,
microsoft
Friday, October 9, 2009
Delay: unclear on the concept
Conversation just finished:
"Your simulator delay variable isn't working."
"I tested it and it delays correctly. What's happening?"
"Every time I set it, I get a CURL 28 timeout error. If I take it out, everything works. You need to fix it."
"... Sounds to me like it's working, the response gets delayed like it's supposed to. You did remember to bump up the timeout setting in AD's config file to something greater than the delay you're setting, right?"
"..."
"If you don't, it'll always time out like that because you're making the simulator delay longer than AD's willing to wait."
"Your simulator delay variable isn't working."
"I tested it and it delays correctly. What's happening?"
"Every time I set it, I get a CURL 28 timeout error. If I take it out, everything works. You need to fix it."
"... Sounds to me like it's working, the response gets delayed like it's supposed to. You did remember to bump up the timeout setting in AD's config file to something greater than the delay you're setting, right?"
"..."
"If you don't, it'll always time out like that because you're making the simulator delay longer than AD's willing to wait."
Labels:
work
nVidia exits the motherboard chipset market
nVidia's known for making graphics chipsets and cards, but they also make another indispensible part of a system: the motherboard support chipset. nVidia's offering is the nForce series of chipsets. But nVidia's leaving that market, at least as far as Intel CPUs are concerned. It's planning to cease making motherboard chipsets to concentrate solely on graphics. This'll leave only two major players making motherboard chipsets: Intel (for Intel CPUs) and AMD (for AMD CPUs). This'll also leave nVidia the odd man out in graphics as the only major player who isn't affiliated with a CPU maker (Intel makes their own video chipsets (albiet very low-end ones) and AMD acquired ATI a while back). This may be a bad move for nVidia, it'll leave Intel and AMD/ATI with a major advantage in terms of integrating graphics chipsets with motherboard/CPU components.
Fortunately my planned motherboards were all going to use AMD chipsets, since I was planning on AMD CPUs and neither Intel nor nVidia make motherboard chipsets for them.
Fortunately my planned motherboards were all going to use AMD chipsets, since I was planning on AMD CPUs and neither Intel nor nVidia make motherboard chipsets for them.
Monday, October 5, 2009
Signs your workplace may not be as professional as they claim to be
First sign: having to explain in small words what "significant digits" are, and why where the decimal point is doesn't matter when dealing with them. The targets of this explanation all have degrees in either computer science or an engineering discipline.
Meanwhile, over in alt.sysadmin.recovery, people with no degrees at all are having intelligent arguments over the differences between the various alephs and whether particular ones are ordinal or cardinal numbers.
Meanwhile, over in alt.sysadmin.recovery, people with no degrees at all are having intelligent arguments over the differences between the various alephs and whether particular ones are ordinal or cardinal numbers.
Labels:
computer science,
math
Friday, July 3, 2009
Computer case
I got the case for my new gateway/router machine: an Antec 300 through Newegg. The nice thing about it's that the power supply mounts in the bottom with the motherboard above. That means fewer cables dangling over everything, and fewer problems getting front-panel cables to reach to the back of the motherboard where some of the headers are. It's also got plenty of fans: one on top, one high on the back, one on the side panel and two behind the front panel. Two downsides, though. The first is that it doesn't have any external 3.5" bays, and the 5.25"-3.5" bay adapters are a pain to get. Not a problem for this machine, it won't have much in the way of USB hanging off it, but it may be a problem for desktop/gaming machines if I can't find decent 5.25" panels. The second is that you can't get at the air filter on the front bezel without taking the side panel off. That makes cleaning the filter a bit more of a pain. Again not a problem with this machine since it'll be sitting where the side panel'll be in the clear, but it may be an issue with machines that'll be under desks.
Another option for a desktop/gaming case is the Antec P183 or P193. Both of those have an external 3.5" bay and filters that seem accessible by opening the front door. I may have to see if someone locally carries them so I can get a hands-on look at them.
Oh, why am I building a new router? The answer lies in the CPU of the current one: a 400MHz AMD K6-3. This is an old Pentium-class. Not P3 or P2, Pentium. It's performance is, bluntly, anemic. I've got a leftover Abit KN8 Ultra motherboard and a CPU to go with it, so that's what I'm turning into a replacement router. It's still old hardware, but it'll be an order of magnitude more powerful than what I've got currently and should handle being a router and access gateway OK.
Another option for a desktop/gaming case is the Antec P183 or P193. Both of those have an external 3.5" bay and filters that seem accessible by opening the front door. I may have to see if someone locally carries them so I can get a hands-on look at them.
Oh, why am I building a new router? The answer lies in the CPU of the current one: a 400MHz AMD K6-3. This is an old Pentium-class. Not P3 or P2, Pentium. It's performance is, bluntly, anemic. I've got a leftover Abit KN8 Ultra motherboard and a CPU to go with it, so that's what I'm turning into a replacement router. It's still old hardware, but it'll be an order of magnitude more powerful than what I've got currently and should handle being a router and access gateway OK.
Labels:
computer case,
hardware
Wednesday, June 24, 2009
What SCO management knew
Lewis Mettler comments on RedHat's filing in the SCO bankruptcy. Now, I disagree with him about SCO management. Darl has been through this kind of thing before. I think SCO's management knew exactly how flimsy and baseless their case was. Whatever their lawyers told them, I think they knew the reality. They'd simply decided that the strength of their case didn't matter. They figured IBM would settle because it was cheaper than fighting and winning.
SCO's problem was just that they miscalculated how IBM would figure the costs. If it's cheaper to settle than to win a lawsuit, you settle. SCO calculated the cost of settling as just the dollars IBM would have to pay them. IBM, though, felt that settling would be taken by their customers as an admission that the accusations had some merit. Since the accusations were that IBM had broken contracts just to make more money, they felt that'd negatively affect their business. Their software business runs around $6 billion a year, so even a 1% drop in business from customers getting nervous about IBM not honoring contract terms would be $60 million a year in lost revenue. That makes settling a lot more expensive, and IBM decided it was cheaper to throw a few tens of millions of dollars at defending their good name than to put hundreds of millions of dollars of revenue at risk.
SCO weren't deceived by their lawyers. They didn't believe they ever had a case. They simply figured that IBM would pay Danegeld if it wasn't too much. And they were wrong.
SCO's problem was just that they miscalculated how IBM would figure the costs. If it's cheaper to settle than to win a lawsuit, you settle. SCO calculated the cost of settling as just the dollars IBM would have to pay them. IBM, though, felt that settling would be taken by their customers as an admission that the accusations had some merit. Since the accusations were that IBM had broken contracts just to make more money, they felt that'd negatively affect their business. Their software business runs around $6 billion a year, so even a 1% drop in business from customers getting nervous about IBM not honoring contract terms would be $60 million a year in lost revenue. That makes settling a lot more expensive, and IBM decided it was cheaper to throw a few tens of millions of dollars at defending their good name than to put hundreds of millions of dollars of revenue at risk.
SCO weren't deceived by their lawyers. They didn't believe they ever had a case. They simply figured that IBM would pay Danegeld if it wasn't too much. And they were wrong.
Tuesday, June 9, 2009
Web fail
A challenge most Web designers today fail: design a generic Web page. It must display readably on a 24" widescreen LCD monitor at 1920x1200 resolution, and readably on the 320x200 pixel display of a Web-capable cel phone. It must not fail to render because the browser lacks Flash, or Java, or .Net or anything else not present in the basic browser installation. It must not fail to render because the user isn't running any particular browser.
For extra points, it must render readably on a 24" widescreen LCD monitor running in 640x480 16-color mode (user has failed their check vs. INT to set the correct monitor type and Windows has defaulted to a minimal known-good resolution).
For extra points, it must render readably on a 24" widescreen LCD monitor running in 640x480 16-color mode (user has failed their check vs. INT to set the correct monitor type and Windows has defaulted to a minimal known-good resolution).
Tuesday, June 2, 2009
System capacity
Immediate thought: if your system gets overloaded handling 20 requests a minute, something's really hosed. I'm used to thinking in terms of rates 10-100x that, and counting them per second not per minute. The problem of course is that the offending software is a commercial package, so we can't dig into it to find out what the problem is and fix it.
Labels:
software
Wednesday, May 6, 2009
News from SCO
Two bits of news about SCO. First, in the bankruptcy case the US Trustee has moved to convert SCO to Chapter 7 liquidation. Second, in the appeal of the judgement in the Novell case, the appeals court heard oral arguments and my first impression is that they weren't impressed with SCO's arguments.
In the appeals hearing, it sounded very much like at least two of the three judges were looking at the contracts themselves, and at SCO's arguments, and going "You know, you're arguing that when the contract says "excludes" it really means "includes". We aren't buying that.". I expect the appeals ruling won't be favorable to SCO.
On the bankruptcy front, the next hearing is June 12th. I suspect the appeals ruling will be in in at least a preliminary form before then. If it goes against SCO, that pretty much shreds the last hope SCO had for postponing the inevitable. And SCO really doesn't want to end up in Chapter 7. When that happens the current executives lose their jobs and the US Trustee takes over management of the company. He's got no dog in the fights between SCO and Novell and IBM, his only interest in them will be to settle them at the minimum cost to the bankruptcy estate. And he'll have access to all SCO's corporate and legal records. Attorney-client privilege won't apply because, as of his appointment, he'll be the client. If he finds records showing SCO knew they didn't have a case when they filed it, he'll have no problem whatsoever filing a sworn statement to that effect in a settlement deal and turning over the records to back it up. That could place BSF in a very bad position. Not that they're in a good one now, mind you.
I've said it before: SCO miscalculated the cost to IBM of fighting. SCO assumed IBM would look at the demand for a few million dollars and count it cheaper than the cost of fighting it out in court and winning. IBM looked at a threat to half or more of their annual revenue world-wide (their gross revenue tops $100 billion), multiplied by decades, and decided a few million was cheap. I can imagine the conversation with their lawyers: "You know it's going to cost to fight this." "Yes, we know. Here's a quarter of a billion for the initial deposit, call us when it gets low and we'll add more.". To give you scale, that's half a percent of the first year of the revenue at risk. IBM's looking at 50 years, most likely (which is less than half the time the company's been in business, they've got current product lines that're nearly that old).
In the appeals hearing, it sounded very much like at least two of the three judges were looking at the contracts themselves, and at SCO's arguments, and going "You know, you're arguing that when the contract says "excludes" it really means "includes". We aren't buying that.". I expect the appeals ruling won't be favorable to SCO.
On the bankruptcy front, the next hearing is June 12th. I suspect the appeals ruling will be in in at least a preliminary form before then. If it goes against SCO, that pretty much shreds the last hope SCO had for postponing the inevitable. And SCO really doesn't want to end up in Chapter 7. When that happens the current executives lose their jobs and the US Trustee takes over management of the company. He's got no dog in the fights between SCO and Novell and IBM, his only interest in them will be to settle them at the minimum cost to the bankruptcy estate. And he'll have access to all SCO's corporate and legal records. Attorney-client privilege won't apply because, as of his appointment, he'll be the client. If he finds records showing SCO knew they didn't have a case when they filed it, he'll have no problem whatsoever filing a sworn statement to that effect in a settlement deal and turning over the records to back it up. That could place BSF in a very bad position. Not that they're in a good one now, mind you.
I've said it before: SCO miscalculated the cost to IBM of fighting. SCO assumed IBM would look at the demand for a few million dollars and count it cheaper than the cost of fighting it out in court and winning. IBM looked at a threat to half or more of their annual revenue world-wide (their gross revenue tops $100 billion), multiplied by decades, and decided a few million was cheap. I can imagine the conversation with their lawyers: "You know it's going to cost to fight this." "Yes, we know. Here's a quarter of a billion for the initial deposit, call us when it gets low and we'll add more.". To give you scale, that's half a percent of the first year of the revenue at risk. IBM's looking at 50 years, most likely (which is less than half the time the company's been in business, they've got current product lines that're nearly that old).
Tuesday, April 7, 2009
The Internet turns 40
The Internet as we know it is 40 years old today. The very first RFC, RFC 1 - Host Software, was published on April 7, 1969.
Labels:
internet
Monday, April 6, 2009
Cloud computing
Cloud computing isn't anything new. WorldNet from "Valentina: Soul in Sapphire" in 1984. "The Adolescence of P-1" in 1977. The idea of a world-wide computer network where programs can run on any processor on the grid isn't new. The hard part, of course, is making it happen. Machine code's specific to a particular processor. You can't run x86 code on a PowerPC CPU without some hairy emulation happening. Ditto for running Windows software on a Linux system, or vice-versa. So the first big technical challenge is making it possible for code to migrate from machine to machine without getting caught in CPU and OS compatibility issues. Things like Java's bytecode solved that, though. From a technical standpoint, there's nothing stopping code from being shifted around between machines as long as the author didn't choose to build hardware-specific executables.
The non-technical problems are bigger, though. The first is obvious: when running on the cloud or the grid or whatever you call it, your programs and data reside on someone else's system. How do you protect your data from being exposed to people who shouldn't see it? How do you force the hardware's owner, someone you may not have a direct contract with, to protect it from theft or damage? How do you insure you can get your data and programs back in the event you want to go elsewhere? They're all intertwined, you know. Amazon, for instance, solves the problems of data exposure and protection by keeping your data only on their systems, where you've got a contract with them. But at the same time, you don't entirely control the data formats. Your data resides on their systems, not yours, and in their formats, not yours. Unless you built special facilities into your software to send you copies of your data, if you decide to move from Amazon to Google you may find Amazon either won't export your data for you or won't export it in a format Google can import. And you may find your programs, written for Amazon's systems and APIs, won't compile for Google's without major rewriting.
The whole idea is a wonderful one, but you need to think about the logistics and remember that there are no silver bullets. There's no magic here. The obvious problems still exist, and still have to be dealt with, and they won't go away just because they're inconvenient to deal with.
The non-technical problems are bigger, though. The first is obvious: when running on the cloud or the grid or whatever you call it, your programs and data reside on someone else's system. How do you protect your data from being exposed to people who shouldn't see it? How do you force the hardware's owner, someone you may not have a direct contract with, to protect it from theft or damage? How do you insure you can get your data and programs back in the event you want to go elsewhere? They're all intertwined, you know. Amazon, for instance, solves the problems of data exposure and protection by keeping your data only on their systems, where you've got a contract with them. But at the same time, you don't entirely control the data formats. Your data resides on their systems, not yours, and in their formats, not yours. Unless you built special facilities into your software to send you copies of your data, if you decide to move from Amazon to Google you may find Amazon either won't export your data for you or won't export it in a format Google can import. And you may find your programs, written for Amazon's systems and APIs, won't compile for Google's without major rewriting.
The whole idea is a wonderful one, but you need to think about the logistics and remember that there are no silver bullets. There's no magic here. The obvious problems still exist, and still have to be dealt with, and they won't go away just because they're inconvenient to deal with.
Thursday, April 2, 2009
Trademark ownership
An interesting decision about trademark ownership. What's interesting about it is that the judge ruled that trademark use trumped a registered trademark. A lot of companies have been treating trademarks as if registration, however recent, trumped all common use no matter how long-term and well-established. The judge here threw that reasoning out, ruling that the Dallas Cowboys, even though they didn't have a formal registration on the phrase "America's Team", nonetheless owned it by virtue of long use of the phrase and it's association with the team. This overturned the relatively recent registration of that phrase as a trademark by another company.
This is good news for people who've been using names and phrases associated with their products. When someone else comes along, registers that name or phrase as a trademark and tries to usurp your usage on the grounds that a registered trademark trumps an unregistered one, you can point to this decision and say "The courts say otherwise.".
This is good news for people who've been using names and phrases associated with their products. When someone else comes along, registers that name or phrase as a trademark and tries to usurp your usage on the grounds that a registered trademark trumps an unregistered one, you can point to this decision and say "The courts say otherwise.".
Labels:
intellectual property,
law,
trademark
Tuesday, March 3, 2009
Google and copyright claims
You know, I'm thinking that Google should be getting a bit more hard-nosed about copyright. When someone sues them claiming that Google can't internally cache anything without permission, Google should simply shrug and immediately blacklist everything by the plaintiff. From that point on, nothing belonging to the plaintiff will appear anywhere in any of Google's services. You don't want Google to maintain even neccesary internal copies of your stuff? Fine, Google won't and you'll live with the consequences.
Note that this is different from distributing copies of your work. Google can't hand out copies of your book. But returning a sentence or two in response to a search query and pointing to where the book can be bought? That's just as fine as a person mentioning something interesting from a book and telling their friend where to buy it. An author doesn't like that, that author gets to live with nobody recommending their books to friends too.
Note that this is different from distributing copies of your work. Google can't hand out copies of your book. But returning a sentence or two in response to a search query and pointing to where the book can be bought? That's just as fine as a person mentioning something interesting from a book and telling their friend where to buy it. An author doesn't like that, that author gets to live with nobody recommending their books to friends too.
Thursday, February 26, 2009
The Kindle 2 and newspapers
Thinking about the Kindle 2, it may be the salvation of newspapers. A lot of the cost of newspapers is in the printing: the paper, the ink, the presses, the cost of distributing the sheer physical mass of paper. The Kindle 2 provides a secure subscription-based channel for delivering black-and-white printed content that doesn't require moving physical material around. Amazon already has a content distribution network set up. A newspaper could mark up their edition electronically and distribute it to Kindles. As long as nobody involved gets greedy, I think it could be profitable once the costs of physical printing and distribution are shed.
Tuesday, February 17, 2009
Verizon using mail submission port 587
Verizon is moving to using port 587 for mail submission, requiring encryption and authentication to send mail. That alone won't stop the spam originating from their networks, but it's a start. My thought is that there should be 3 ports for 3 different purposes:
- Port 25, no encryption or authentication required, is for server-to-server mail transfer. Relaying shouldn't be allowed, all e-mail arriving should be addressed to an in-network domain. Anything else should be rejected. This means no relaying. Messages should not be modified except for adding an appropriate Received header.
- Port 587, encryption and authentication required, is for end-user mail submission only. Mail submitted to it should have the Sender header stripped and replaced with one based on the authenticated username.
- Port 465, encryption required and authentication allowed, is a hybrid. If the session isn't authenticated, it should act per the rules for port 25. Authenticated sessions should be allowed to relay. If relaying, authentication information should be added to the Received header and if no Sender header is present one should be added based on the authentication information. Messages should not be otherwise altered.
The Pirate Bay trial
Apparently half the charges against The Pirate Bay have been dropped by the prosecution. This isn't based on a technicality, as I read it, but on such basic things as the screenshots the prosecution was using as evidence the client was connected to the TPB tracker clearly saying it was not connected to the tracker. It's no wonder the prosecution dropped those charges rather than continue. If they'd've continued, the defense would've introduced the prosecution's own screenshots and the prosecutor wouldn't've been able to rebut them.
I don't particularly agree with piracy, but when the prosecutors screw up this badly they deserve to lose.
I don't particularly agree with piracy, but when the prosecutors screw up this badly they deserve to lose.
Labels:
copyright,
law,
peer to peer,
the pirate bay
Thursday, February 12, 2009
Code comments
Motivated by a Daily WTF entry on code comments. I know exactly what creates this: Comp Sci instructors. You know them, the ones who insist that every line of code be commented, no matter how trivial. After a couple of years of this, students get in the habit of including comments just to have a comment for that line of code. Of course the easy way to do this is to just restate what the line of code does.
Now, as a professional programmer doing maintenance on code I don't need to know what the code does. I can read that line of code and see exactly what it does. I need something a bit higher-level. I need to know what the code's intended to do, and I need to know why it's doing it and why that way of doing it was selected. I know it's interating down a list looking for an entry, I need to know what that list is for and why the code's looking for that particular entry. Instead of comments describing how to iterate through a list, I need a block comment saying something like "We've got our list of orders entered this week, we know they're ordered by vendor, and we're trying to find the first order for a particular vendor so we can extract all his orders quickly.". Probably followed by something like "Now that we have this vendor's first order, we'll grab everything until we see the vendor number change. When we see that, we've got all his orders.". Much shorter, wouldn't satisfy that instructor at all since most of the code won't be commented, but much much more useful when I have to change things. It tells me what the code's trying to do, and what assumptions it's making that I have to avoid invalidating.
Too many Comp Sci teachers need some real-life experience maintaining the kind of code they exhort their students to produce.
Now, as a professional programmer doing maintenance on code I don't need to know what the code does. I can read that line of code and see exactly what it does. I need something a bit higher-level. I need to know what the code's intended to do, and I need to know why it's doing it and why that way of doing it was selected. I know it's interating down a list looking for an entry, I need to know what that list is for and why the code's looking for that particular entry. Instead of comments describing how to iterate through a list, I need a block comment saying something like "We've got our list of orders entered this week, we know they're ordered by vendor, and we're trying to find the first order for a particular vendor so we can extract all his orders quickly.". Probably followed by something like "Now that we have this vendor's first order, we'll grab everything until we see the vendor number change. When we see that, we've got all his orders.". Much shorter, wouldn't satisfy that instructor at all since most of the code won't be commented, but much much more useful when I have to change things. It tells me what the code's trying to do, and what assumptions it's making that I have to avoid invalidating.
Too many Comp Sci teachers need some real-life experience maintaining the kind of code they exhort their students to produce.
Labels:
computer science,
software,
teachers
Tuesday, February 3, 2009
Powerful and easy to use
"You'll find this system to be incredibly flexible and powerful. You'll also find it to be incredibly simple and easy to use with minimal training. However, don't ask it to be both at the same time."
Labels:
engineering,
it,
software
Subscribe to:
Posts (Atom)