This is EXACTLY the kind of thing that pisses me off to no end.
Companies/people who think that education and/or certification justifies someone being given a job.
Go back and re-read what I said. The key is "all things being equal."
The last position I posted I got 300 resumes. That's after HR weeded out the junk. I did phone interviews with 20 of them and in-person interviews with another 15. No, they didn't all have college degrees - maybe only half did. Experience definitely counts more than education.
At the end of the day, I had 3 awesome candidates. All three could easily work with our users, understand our business processes, and was willing to support something from front-line to systems implementation. They were all excited, all motivated, and in general great people. Did it matter that the guy who got the job had a CS degree? Well, the other two guys were great systems guys (1 had a degree, 1 didn't), but the guy with a CS degree got it because he had a lot of experience while in college doing some DB integration work.
People who think they're a millions times more talented than the guy in line behind them are gravely mistaken. Anyone who thinks they have job security and are irreplacable are sadly out of touch with corporate America - there are few companies in the country that have loyalty to their employees. It's tough times for anyone looking for a job right now and there's plenty of qualified candidates available. So given the glut of potential candidates available do you think majority of the best candidates will have degrees or not? Phrased in another way, thinking of the best programmers and sys admins you know, do the majority have degrees or not?
I manage an area that fortunately has lots of people interested in working for us, doing sys admin work amongst other things. I wouldn't hire you. The problem is, all things being equal, the guy with a college education is going to win. Unfortunately, all things generally are equal. There's no shortage of people with good attitudes, good experience, and are bright. So, often the education becomes a focus. It proves you know how to learn, can follow directions, and have some discipline to pursue a long-term goal.
Now, having said that, if one of my friends told me I had to hire you, I'd generally trust them and do it. So, it's possible to work your way up, but it's hard.
I recommend working for the phone company. It's more interesting than computers anyway.
Already Happening - Resort Communities
on
Houses With Tails
·
· Score: 1
This is already happening (and has been for years) in resort communities. Typically the arrangement starts with a central authority, in Colorado I worked with a few unincorporated Metro Districts for example, that owns and maintains all of the infrastructure. The infrastructure provided service to most homes and condos. The arrangement to provide service was made with a property management company that in turn contracted with the individual homeowner associations. The HOA assessed dues and the property management company collected the dues. Then the property management company reimbursed the utilities for their service.
In practice, things were quite as clean. Besides the service provided by the metro district, service was also provided by the local telco if the individual homeowners wanted that instead.
Anyway, resort communities provide a pretty good model for how to do it in the rest of the country.
So this stuff probably isn't monitoring LAN or even WAN traffic, it's probably only Internet traffic. Someone else mentioned a proxy server, something like squid. (Of course, the obvious answer is the ad block, blah blah blah.) Therefore, set up a proxy server and share it between a bunch of users. You'll get an even better economy of scale on the bandwidth usage.
There's a lot of other little tricks you can do, external proxy, compress all traffic in between, et al. However, this question (and so far 99% of the answers) is pretty newbie and I just want to slap you and say "Duh." I did like the response about Opera - I've stayed away from it for years, but maybe I need to take another look.
First off, I like the idea of intercepting this with an auto attendant, I think that's the simplest and most important thing you can do in the short term. I think you could ask your local telco if they can put an intercept message on the line - that should be completely possible. If not, look for some kind of device that will pick up, play back a recorded message, then pass the call on to the phone. A service like this would work well but costs money:
Or, you can probably do some call forwarding tricks, but that will require switching the number to a different carrier because a regular 1FR line won't do the necessary tricks.
Oh, and some idiot on this forum is going to suggest doing some tricks with Asterisk - ignore them because it's 20 times more work than you need to do and in the end it's just going to confuse her.
To really nab these guys, you're going to need to some how trace it back to the origin, and that's going to be damn hard. If you can't get a callback number to trace it with, then it would be nice if you could some how get ANI (automatic number identification) information. And that could be possible. Do it this way: find an agreeable caller who'll work to help nab this guy. Then get them to go to their telco and request their phone records get pulled and the ANI from the phone call retrieved. Then go to the telco's with that ANI and find out who owns it. Anyone can spoof caller ID, but it takes some real magic to spoof ANI. (Unfortunately some carriers toss away ANI records and translate caller ID to ANI, so be careful. It may take a few interations to get that info.)
Now, that's still probably not going to work. I have no doubt these guys are offshore and using a VOIP box (probably Asterisk, lol). The VOIP calls terminate to a VOIP carrier in the US with an account that was set up under some fraudulent information. Then that VOIP carrier is peered with the real telco's via some regular old PRI's and that's the ANI information you'll get. However, I have no doubt that somewhere, some how a bill is generated and paid for, so if you can get to the VOIP carrier, you might be able to track this down.
Lots of people here are suggesting a super-broad physics education focusing on everything from themo to relativity to quantum mechanics. These are VERY diverse areas and I really don't think you have time to learn any of them very good, let alone all of them. Therefore, I'd focus on the areas you're likely to delve into first - things like relativity and basic mechanics/dynamics.
In that regard, Feynman's Lecture series is excellent. For a quick read, I'd recommend Feynman's Six Not So Easy Pieces. You might be able to blow through it in a day.
After coming up to speed on some of that stuff, delve into thermodynamics and electromagnetics. Save quantum mechanics for the very end - it's probably the furthest thing from what you'll need to know.
Unless you have a specific career goal in mind, it's a waste of time right now and you can pick it up later. In fact, go work for an employer who'll pay for continuing education and learn it on their dime.
My recommendation - do the bare minimum to get your degree. Everything you learn on the job will be completely different. Caveat: some obscure area you can only learn at a university. Otherwise, party your ass off, have promiscuous sex, and throw caution to the wind. You won't have many more chances.
Wow.. a decade ago knowing about screen would have been pretty common and necessary knowledge. Now we have to Ask Slashdot for instructions for using it?
It seems like we've some how failed in the Linux community to instill this knowledge. Even worse, Soulskill felt that it was important enough to warrant posting to Ask Slashdot.
Don't get me wrong - I don't think we need another tutorial. In fact, quite the opposite. I bet if you put "screen tutorial" into Google it'll come up with tens of thousands of matches. Instead, we really need some way to educate people on using Linux and doing it in such a way that people will actually learn it quickly. It's the million dollar question and I don't think any of us know the answer.
Ironically, the way we've chosen to integrate users into the community is to make all of our concepts like Windows - windowing, mouse events, session initiating, etc. I don't think that's a bad thing at all and anything that expands the community is good. But it also makes people think within the same box they've always known. Linux lets you do a lot of other things - those need to be championed!
(On a side note, I had a Sun engineer explain ZFS to me. Up until then, I had just written it off as another advanced filesystem. Once I 'got it' I realized what a powerful concept it was and how those filesystem changes made me rethink everything I knew about how applications interact with the OS.)
Over the past few years we've seen major architectural concerns calm down. The DLL separation took a while, we had the major filesystem rewrite, and then in the past year we had the big windowing changes. Oh, and then throw in the big changes to support copy protection, real services, and oodles of D3D updates.
So where does that leave us? Are there any major architectural changes in the pipe? There are rumors Codeweavers will integrate a DIB engine - what does that do and why is that necessary? What about in the RPC world? Jeremy - you've battled with audio, how do you feel Wine is doing with regards to audio support?
This probably has more to do with a tower/repeater location than anything having to do with CDMA or GSM. You probably have a GSM tower much closer to you than a CDMA tower. It could even have to do with the size of the antenna on the Tracfone.
However, before we get to that, let me just say I think this is a good thing. I've managed several large cell accounts (500+ handsets) and I've had great experiences with Verizon - their business side is great. At least the reps I've dealt with. Conversely, the company I work for now has Alltel and I think they f*cking suck. For reference though, AT&T is the worst company I've ever deal with (500+ account). Then again, I've never dealt with Sprint. This is probably a regional thing, YMMV.
Anyway, our rep had some interesting news today. Now, Alltel services some VERY rural areas including this remote area of Montana that I live in. According to her, Alltel in Montana will never be operated as Verizon, it is impossible due to FCC regulation. After the sale is complete, Verizon will have to divest our market and any others acquired in which there was direct competition (A & B side carrier designation).... to yet another carrier. This will be a good chunk of real estate so the expectation is that it will be to another major player.
So what does that mean? Verizon is going to suck up a lot of urban areas and urban customers and rural customers are likely to get shafted. Shafted meaning they will be transferred to odd little local carriers (yes - they still exist), such as Chinook. Why? Because Sprint still hasn't built out their PCS network in lots of rural areas. AT&T's GSM still has poor coverage in many areas too compared to Verizon & Alltel's older CDMA technology. Also, rural areas are very expensive to install infrastructure in, especially if you're dealing with mountains.
My recommendation for anyone maintaining a large cell account: stop buy equipment and renewing contracts. This deal will likely take 6 months for acquisition, and then a year for assimilation. That means, get your existing contracts as close to expiration as you can so that you're not incurring costs to break your contract. Right now breaking an Alltel contract is approximately $175/line.
Right now the landscape for various projects is really a mess. Everyone kind of has their own release schedule and it's different for every project - and for good reason: we're doing this on our own time and therefore why should we care about ship dates?
Well, realistically we do. If projects knew that every May and every November there'd be major distro releases, they'd probably do a good job of freezing their trees in January and July to prepare point releases aimed at being relatively stable.
In turn, there'd be a nice set of releases that Red Hat could pick from and decrease their QA. Otherwise, it's kind of scattershot what the condition of various projects' trees are in.
Alright guys, this release is 15 years in coming. I'm not aware of any other free software project that's taken 15 years to get to 1.0.
We know we've got some core architecture just right. That's taken a long time to get there. Now we have a lot of bug squashing to do and in many cases it's pretty amazing how quickly regressions can be found, bugs tracked, etc if we just have a few more eyes on this release.
So we put together a list of things you can do to help us out - check it out here: 1.0 regression hunting. And hey! We're giving out t-shirts to the folks who help us out the most.
Notice we didn't say anything about jumping in and writing code? You're certainly welcome to, and in some cases there might even be some low hanging fruit. However, without development experience on Wine's codebase your valuable time might best be spent regression testing your favorite game!
We know those stats aren't quite accurate. Here's basically how we generate them: we ask the various subsystems maintainers, "How close to complete do you think this is?" and then we munge in some true numbers on actual function calls (API's) exported by DLL's and the number we've implemented (and in and of themselves each API might not be 100% complete.)
So take those numbers with a grain of salt. In some cases, it's completely possible a DLL will be nearly 100% functional with not many of the API's implemented at all. Microsoft has invented thousands of API's over the years and some have been dead on arrival - no one has ever used them. Even Microsoft doesn't use all of their API's. That's why within Wine development there's an often cited development method of, "Show me an app that actually uses that."
Finally, Tom hasn't updated those stats in almost a year and we've done a lot of work since then. (Big kudos to Tom Wickline for tackling that stuff.)
So what Wine really aims for is to take the most common few thousand API's and try to do them really well. Then we flesh out some bits around that. Then we stub out things around that and finally there's bits we just haven't even started.
True - they might end up overtaking Wine at some point. Wine started in 1993. I think E started in 1996 or 1997. Wine is slated to hit 1.0 in June of this year (really! we have a release schedule now!) E just has to continue plodding along for another 3 or 4 years to overtake us.
Microsoft isn't stupid and they seem to be realizing this trend is coming. Have you looked at their product roadmap and how it all has to work together?
It goes something like this:
Develop very nice server side applications that are pretty easy to use, simple to administer, etc. This would be things like their Dynamics platforms, Dynamics GP, Exchange, CRM, and Project Server.
Make sure they only run on expensive MS Server 2008 platforms. Charge lots of money for MS Server 2008 and the associated CALs.
Make sure they really only interoperate with MS Windows clients.
Add insult to injury by inserting a middleware package called Sharepoint that is ridiculously expensive.
I hate Microsoft, but the apps I mentioned above are actually pretty decent and they drive all of our business decisions from there (server OS, client OS, etc).
1. First off, you dismissed WAFS-style accelerator solutions - I wouldn't. I think that's going to go a long toward your solution.
3. Get more bandwidth bang for your buck by consolidating all your connections through 1 carrier (realistically it probably isn't possible, but you might get close.) Something like Megapath. See if you can find someone to build you an MPLS network so you can guarantee layer 3 throughout. Build QoS policies on that. By going with 1 carrier you'll make your account management simpler and they might give you more bandwidth because they're carrying all your traffic. Be prepared to sign a 3 or 5 year contract for the best deal.
2. You were worried about authentication over the WAN - shouldn't matter because that's fairly low bandwidth. Print queues over the WAN? Egad - you don't want to do that so come up with a novel solution for dropping some kind of network printer on their LAN. Novel might just mean a sleeve on the side of the printer that holds the driver installation CD. Users can be walked through that. At the same time, make sure all your printers are the same so your help desk isn't bogged down in troubleshooting a million different ones.
4. Application selection: this is pretty critical. Don't purchase heavy apps. Purchase lightweight, web-based ones. For example, your accounting system might have a fat client for everyone in the home office and then a web version for everyone else. That'll work fine since they're probably just doing boring things like generating PO's. Microsoft Project has a web client within their MS Project Server, so that'll work for something like that. Just keep this in mind when purchasing any application.
These were pointed out by others, but I strongly feel the two most important keys to success for an open source project are marketing and modularity. Like someone else said, hit the pavement and sell your work. You better be good at it, because it's a lot harder than you think. If you aren't good, find someone else and have them work solely on commission if you can't afford to pay them. Second point: modularize your software. Keep a portion of it non-free and make money off selling it.
Of course, everyone always says "sell service and support". Guess what: service and support are the two worst aspects of software. They're not fun, they can be tedious, and it can be a lot of work to get them to pay for themselves when you're first starting. Why would you want your bread and butter to be the most grueling part of your job?
Anyone ever hear of the book "No Asshole Rule"? It applies to hiring and firing staff (and if you're a manager you should probably browse through it.) On a real gut level I think corporations should abide by the ideas in that book. If you can't play nice in the playground with the other kids, you deserve to get your face punched in. Similarly, if you build your business on open source software, you play nice by going to the software developers and saying, "We think you're infringing this IP.. can you work with us to fix that?" If you wanna be the asshole that goes around suing everyone, blatantly lying to the press, and tell Wall Street another set of lies then you deserve to file bankruptcy.
Question: Trends
on
Ask Rob Malda
·
· Score: 4, Interesting
You've probably followed more news stories and trends over the past decade than just about anyone else.
Based on that, what are your predictions for the next 10 years?
Some technology is obviously going to die a quick and painful death. Some of that technology will be good and some deservedly bad. What's going to catch on? What has staying power? Google has been a golden child the last few years, will that continue? Are there any big turnarounds coming? Who's got good stuff in the pipeline? Don't you dare tell me 2008 is the year of Linux (and I know you won't) - we've both been hearing that marketing crap for the past 10 years.
Wine's Direct3D has taken amazing leaps over the past year. Maybe id should contribute a little love to that project to come up with a native version similar to how Google did Picasa?
Slashdot Mirror
Yes, location and the nature of the job are 90% of the reason we have such a great talent pool. We're building a ski resort in Montana.
This is EXACTLY the kind of thing that pisses me off to no end.
Companies/people who think that education and/or certification justifies someone being given a job.
Go back and re-read what I said. The key is "all things being equal."
The last position I posted I got 300 resumes. That's after HR weeded out the junk. I did phone interviews with 20 of them and in-person interviews with another 15. No, they didn't all have college degrees - maybe only half did. Experience definitely counts more than education.
At the end of the day, I had 3 awesome candidates. All three could easily work with our users, understand our business processes, and was willing to support something from front-line to systems implementation. They were all excited, all motivated, and in general great people. Did it matter that the guy who got the job had a CS degree? Well, the other two guys were great systems guys (1 had a degree, 1 didn't), but the guy with a CS degree got it because he had a lot of experience while in college doing some DB integration work.
People who think they're a millions times more talented than the guy in line behind them are gravely mistaken. Anyone who thinks they have job security and are irreplacable are sadly out of touch with corporate America - there are few companies in the country that have loyalty to their employees. It's tough times for anyone looking for a job right now and there's plenty of qualified candidates available. So given the glut of potential candidates available do you think majority of the best candidates will have degrees or not? Phrased in another way, thinking of the best programmers and sys admins you know, do the majority have degrees or not?
I manage an area that fortunately has lots of people interested in working for us, doing sys admin work amongst other things. I wouldn't hire you. The problem is, all things being equal, the guy with a college education is going to win. Unfortunately, all things generally are equal. There's no shortage of people with good attitudes, good experience, and are bright. So, often the education becomes a focus. It proves you know how to learn, can follow directions, and have some discipline to pursue a long-term goal.
Now, having said that, if one of my friends told me I had to hire you, I'd generally trust them and do it. So, it's possible to work your way up, but it's hard.
I recommend working for the phone company. It's more interesting than computers anyway.
This is already happening (and has been for years) in resort communities. Typically the arrangement starts with a central authority, in Colorado I worked with a few unincorporated Metro Districts for example, that owns and maintains all of the infrastructure. The infrastructure provided service to most homes and condos. The arrangement to provide service was made with a property management company that in turn contracted with the individual homeowner associations. The HOA assessed dues and the property management company collected the dues. Then the property management company reimbursed the utilities for their service.
In practice, things were quite as clean. Besides the service provided by the metro district, service was also provided by the local telco if the individual homeowners wanted that instead.
Anyway, resort communities provide a pretty good model for how to do it in the rest of the country.
So this stuff probably isn't monitoring LAN or even WAN traffic, it's probably only Internet traffic. Someone else mentioned a proxy server, something like squid. (Of course, the obvious answer is the ad block, blah blah blah.) Therefore, set up a proxy server and share it between a bunch of users. You'll get an even better economy of scale on the bandwidth usage.
There's a lot of other little tricks you can do, external proxy, compress all traffic in between, et al. However, this question (and so far 99% of the answers) is pretty newbie and I just want to slap you and say "Duh." I did like the response about Opera - I've stayed away from it for years, but maybe I need to take another look.
First off, I like the idea of intercepting this with an auto attendant, I think that's the simplest and most important thing you can do in the short term. I think you could ask your local telco if they can put an intercept message on the line - that should be completely possible. If not, look for some kind of device that will pick up, play back a recorded message, then pass the call on to the phone. A service like this would work well but costs money:
http://www.americanvoicemail.com/autoattendant.html
Or, you can probably do some call forwarding tricks, but that will require switching the number to a different carrier because a regular 1FR line won't do the necessary tricks.
Oh, and some idiot on this forum is going to suggest doing some tricks with Asterisk - ignore them because it's 20 times more work than you need to do and in the end it's just going to confuse her.
To really nab these guys, you're going to need to some how trace it back to the origin, and that's going to be damn hard. If you can't get a callback number to trace it with, then it would be nice if you could some how get ANI (automatic number identification) information. And that could be possible. Do it this way: find an agreeable caller who'll work to help nab this guy. Then get them to go to their telco and request their phone records get pulled and the ANI from the phone call retrieved. Then go to the telco's with that ANI and find out who owns it. Anyone can spoof caller ID, but it takes some real magic to spoof ANI. (Unfortunately some carriers toss away ANI records and translate caller ID to ANI, so be careful. It may take a few interations to get that info.)
Now, that's still probably not going to work. I have no doubt these guys are offshore and using a VOIP box (probably Asterisk, lol). The VOIP calls terminate to a VOIP carrier in the US with an account that was set up under some fraudulent information. Then that VOIP carrier is peered with the real telco's via some regular old PRI's and that's the ANI information you'll get. However, I have no doubt that somewhere, some how a bill is generated and paid for, so if you can get to the VOIP carrier, you might be able to track this down.
Use Outlook with CrossOver Office. CodeWeavers supports Outlook 2003 which should provide a MAPI implementation compatible with Exchange 2007.
I thought the big problem was key distribution, not actual transmission - and this doesn't seem to solve that problem.
Then again, I shouldn't even pretend to understand anything that starts with the word "quantum".
Lots of people here are suggesting a super-broad physics education focusing on everything from themo to relativity to quantum mechanics. These are VERY diverse areas and I really don't think you have time to learn any of them very good, let alone all of them. Therefore, I'd focus on the areas you're likely to delve into first - things like relativity and basic mechanics/dynamics.
In that regard, Feynman's Lecture series is excellent. For a quick read, I'd recommend Feynman's Six Not So Easy Pieces. You might be able to blow through it in a day.
After coming up to speed on some of that stuff, delve into thermodynamics and electromagnetics. Save quantum mechanics for the very end - it's probably the furthest thing from what you'll need to know.
Unless you have a specific career goal in mind, it's a waste of time right now and you can pick it up later. In fact, go work for an employer who'll pay for continuing education and learn it on their dime.
My recommendation - do the bare minimum to get your degree. Everything you learn on the job will be completely different. Caveat: some obscure area you can only learn at a university. Otherwise, party your ass off, have promiscuous sex, and throw caution to the wind. You won't have many more chances.
Wow.. a decade ago knowing about screen would have been pretty common and necessary knowledge. Now we have to Ask Slashdot for instructions for using it?
It seems like we've some how failed in the Linux community to instill this knowledge. Even worse, Soulskill felt that it was important enough to warrant posting to Ask Slashdot.
Don't get me wrong - I don't think we need another tutorial. In fact, quite the opposite. I bet if you put "screen tutorial" into Google it'll come up with tens of thousands of matches. Instead, we really need some way to educate people on using Linux and doing it in such a way that people will actually learn it quickly. It's the million dollar question and I don't think any of us know the answer.
Ironically, the way we've chosen to integrate users into the community is to make all of our concepts like Windows - windowing, mouse events, session initiating, etc. I don't think that's a bad thing at all and anything that expands the community is good. But it also makes people think within the same box they've always known. Linux lets you do a lot of other things - those need to be championed!
(On a side note, I had a Sun engineer explain ZFS to me. Up until then, I had just written it off as another advanced filesystem. Once I 'got it' I realized what a powerful concept it was and how those filesystem changes made me rethink everything I knew about how applications interact with the OS.)
Hm... I'll bite!
Over the past few years we've seen major architectural concerns calm down. The DLL separation took a while, we had the major filesystem rewrite, and then in the past year we had the big windowing changes. Oh, and then throw in the big changes to support copy protection, real services, and oodles of D3D updates.
So where does that leave us? Are there any major architectural changes in the pipe? There are rumors Codeweavers will integrate a DIB engine - what does that do and why is that necessary? What about in the RPC world? Jeremy - you've battled with audio, how do you feel Wine is doing with regards to audio support?
This probably has more to do with a tower/repeater location than anything having to do with CDMA or GSM. You probably have a GSM tower much closer to you than a CDMA tower. It could even have to do with the size of the antenna on the Tracfone.
I learned something interesting today.
/line.
However, before we get to that, let me just say I think this is a good thing. I've managed several large cell accounts (500+ handsets) and I've had great experiences with Verizon - their business side is great. At least the reps I've dealt with. Conversely, the company I work for now has Alltel and I think they f*cking suck. For reference though, AT&T is the worst company I've ever deal with (500+ account). Then again, I've never dealt with Sprint. This is probably a regional thing, YMMV.
Anyway, our rep had some interesting news today. Now, Alltel services some VERY rural areas including this remote area of Montana that I live in. According to her, Alltel in Montana will never be operated as Verizon, it is impossible due to FCC regulation. After the sale is complete, Verizon will have to divest our market and any others acquired in which there was direct competition (A & B side carrier designation).... to yet another carrier. This will be a good chunk of real estate so the expectation is that it will be to another major player.
So what does that mean? Verizon is going to suck up a lot of urban areas and urban customers and rural customers are likely to get shafted. Shafted meaning they will be transferred to odd little local carriers (yes - they still exist), such as Chinook. Why? Because Sprint still hasn't built out their PCS network in lots of rural areas. AT&T's GSM still has poor coverage in many areas too compared to Verizon & Alltel's older CDMA technology. Also, rural areas are very expensive to install infrastructure in, especially if you're dealing with mountains.
My recommendation for anyone maintaining a large cell account: stop buy equipment and renewing contracts. This deal will likely take 6 months for acquisition, and then a year for assimilation. That means, get your existing contracts as close to expiration as you can so that you're not incurring costs to break your contract. Right now breaking an Alltel contract is approximately $175
Right now the landscape for various projects is really a mess. Everyone kind of has their own release schedule and it's different for every project - and for good reason: we're doing this on our own time and therefore why should we care about ship dates?
Well, realistically we do. If projects knew that every May and every November there'd be major distro releases, they'd probably do a good job of freezing their trees in January and July to prepare point releases aimed at being relatively stable.
In turn, there'd be a nice set of releases that Red Hat could pick from and decrease their QA. Otherwise, it's kind of scattershot what the condition of various projects' trees are in.
Alright guys, this release is 15 years in coming. I'm not aware of any other free software project that's taken 15 years to get to 1.0.
We know we've got some core architecture just right. That's taken a long time to get there. Now we have a lot of bug squashing to do and in many cases it's pretty amazing how quickly regressions can be found, bugs tracked, etc if we just have a few more eyes on this release.
So we put together a list of things you can do to help us out - check it out here:
1.0 regression hunting. And hey! We're giving out t-shirts to the folks who help us out the most.
Notice we didn't say anything about jumping in and writing code? You're certainly welcome to, and in some cases there might even be some low hanging fruit. However, without development experience on Wine's codebase your valuable time might best be spent regression testing your favorite game!
As always, thanks for all the support!
We know those stats aren't quite accurate. Here's basically how we generate them: we ask the various subsystems maintainers, "How close to complete do you think this is?" and then we munge in some true numbers on actual function calls (API's) exported by DLL's and the number we've implemented (and in and of themselves each API might not be 100% complete.)
So take those numbers with a grain of salt. In some cases, it's completely possible a DLL will be nearly 100% functional with not many of the API's implemented at all. Microsoft has invented thousands of API's over the years and some have been dead on arrival - no one has ever used them. Even Microsoft doesn't use all of their API's. That's why within Wine development there's an often cited development method of, "Show me an app that actually uses that."
Finally, Tom hasn't updated those stats in almost a year and we've done a lot of work since then. (Big kudos to Tom Wickline for tackling that stuff.)
So what Wine really aims for is to take the most common few thousand API's and try to do them really well. Then we flesh out some bits around that. Then we stub out things around that and finally there's bits we just haven't even started.
True - they might end up overtaking Wine at some point. Wine started in 1993. I think E started in 1996 or 1997. Wine is slated to hit 1.0 in June of this year (really! we have a release schedule now!) E just has to continue plodding along for another 3 or 4 years to overtake us.
Well, there's no hope of beating Wine now as the longest actively developed project without a 1.0 release.
Microsoft isn't stupid and they seem to be realizing this trend is coming. Have you looked at their product roadmap and how it all has to work together?
It goes something like this:
I hate Microsoft, but the apps I mentioned above are actually pretty decent and they drive all of our business decisions from there (server OS, client OS, etc).
This is a topic near and dear to my heart.
1. First off, you dismissed WAFS-style accelerator solutions - I wouldn't. I think that's going to go a long toward your solution.
3. Get more bandwidth bang for your buck by consolidating all your connections through 1 carrier (realistically it probably isn't possible, but you might get close.) Something like Megapath. See if you can find someone to build you an MPLS network so you can guarantee layer 3 throughout. Build QoS policies on that. By going with 1 carrier you'll make your account management simpler and they might give you more bandwidth because they're carrying all your traffic. Be prepared to sign a 3 or 5 year contract for the best deal.
2. You were worried about authentication over the WAN - shouldn't matter because that's fairly low bandwidth. Print queues over the WAN? Egad - you don't want to do that so come up with a novel solution for dropping some kind of network printer on their LAN. Novel might just mean a sleeve on the side of the printer that holds the driver installation CD. Users can be walked through that. At the same time, make sure all your printers are the same so your help desk isn't bogged down in troubleshooting a million different ones.
4. Application selection: this is pretty critical. Don't purchase heavy apps. Purchase lightweight, web-based ones. For example, your accounting system might have a fat client for everyone in the home office and then a web version for everyone else. That'll work fine since they're probably just doing boring things like generating PO's. Microsoft Project has a web client within their MS Project Server, so that'll work for something like that. Just keep this in mind when purchasing any application.
These were pointed out by others, but I strongly feel the two most important keys to success for an open source project are marketing and modularity. Like someone else said, hit the pavement and sell your work. You better be good at it, because it's a lot harder than you think. If you aren't good, find someone else and have them work solely on commission if you can't afford to pay them. Second point: modularize your software. Keep a portion of it non-free and make money off selling it.
Of course, everyone always says "sell service and support". Guess what: service and support are the two worst aspects of software. They're not fun, they can be tedious, and it can be a lot of work to get them to pay for themselves when you're first starting. Why would you want your bread and butter to be the most grueling part of your job?
Anyone ever hear of the book "No Asshole Rule"? It applies to hiring and firing staff (and if you're a manager you should probably browse through it.) On a real gut level I think corporations should abide by the ideas in that book. If you can't play nice in the playground with the other kids, you deserve to get your face punched in. Similarly, if you build your business on open source software, you play nice by going to the software developers and saying, "We think you're infringing this IP.. can you work with us to fix that?" If you wanna be the asshole that goes around suing everyone, blatantly lying to the press, and tell Wall Street another set of lies then you deserve to file bankruptcy.
You've probably followed more news stories and trends over the past decade than just about anyone else.
Based on that, what are your predictions for the next 10 years?
Some technology is obviously going to die a quick and painful death. Some of that technology will be good and some deservedly bad. What's going to catch on? What has staying power? Google has been a golden child the last few years, will that continue? Are there any big turnarounds coming? Who's got good stuff in the pipeline? Don't you dare tell me 2008 is the year of Linux (and I know you won't) - we've both been hearing that marketing crap for the past 10 years.
Wine's Direct3D has taken amazing leaps over the past year. Maybe id should contribute a little love to that project to come up with a native version similar to how Google did Picasa?