If your incoming mail server is an Exchange box, use IMAP - that way the TNEF is decoded on the server
Thanks! I'm getting login verification errors using IMAP with NTLM / SPA authentication (required for Exchange?), though there are some notes on this and it looks 'solveable'.
...what exactly are the issues that Joerg has with Linux's SCSI layer? I've heard about this in bits and pieces for years, but never really understand what the beef is. I've heard it mentioned that he wants to only talk to devices as if they are SCSI, but I don't know how true this is, nor what the real issues he has beyond this are. Anyone?
I'm with you. I don't get the complaint except that he doesn't like how Linux implements SCSI. He seems really annoyed, though I don't understand the technical nature of his complaint.
Wow it only took 10 years to get reliable sound support into the kernel;-)
That's not insightful, it's funny.
On a serious note, I've used the OSS modules for 5+ years, and it's worked well for me. Alsa is quite nice and I'm glad to see it as the default in the kernel now, though OSS is not unreliable by a long shot.
Linux SCSI subsystem a gripe of JS for years
on
More On The 2.6 Kernel
·
· Score: 3, Insightful
Linus and Joerg Schilling, author of cdrtools disagree on whether the problems are with Linux or the application software.
Joerg has complained about Linux for years (4? +5?), and generally perfers the SCSI subsystem in Solaris.
My opinion right now is that Linus is sticking his head in the sand on this issue...other stuff I've read he seems to fully support how nVidia is working, but then allows changes to APIs that clearly theaten that way of working????
Linus himself says very little on the whole binary vs. source module issue.
The concensus on the list is that since Linux is licenced under the GPL it is up to the maker of binary-only modules to support them. The kernel and modules are designed to be a single unit, and compiled as a set. That means that when the kernel changes, the modules are changed as well -- sometimes not just the entry points, but also the internal APIs. Extentions to Linux should be in user space, not in the kernel. If a module needs to be in the kernel, the mainline kernel developers aren't going to bother working on someone else's code if they won't show the code!
If a manufacturer says "well, sorry, I want to support linux, but not if it means letting the competition get a sneak peak at this crazy technology in my drivers" you would just say, "ok, parasite, we don't need your stupid hardware."
The manufacturer is selling hardware. Anything they want to protect from being exposed in the module means little to other hardware companies who have competent developers. The details of how the hardware is controlled and any setup and tables can be discovered using the Windows drivers and debuggers.
Contrary example: In Nvidia's case, they don't own everything they ship so unless they convince other companies to opening those parts (unlikely) Nvidia has to either drop those parts or replace them.
The motivations of different companies are important. Server-grade hardware companies fall all over themselves supporting Linux in the main kernel source tree. If Linux becomes popular on the desktop -- even if modestly so -- the kernel modules that support desktop software will likely be open. Nvidia might even change (though this is speculation on my part).
I see it as encouraging companies *not* to contribute. Why give people Free code when you don't have to?
A few plusses just for maintenance come to mind, there are likely more for maintenance and other reasons such as good PR;
As the kernel changes, the module is kept in sync almost automatically
Others can look at and make changes, fixing defects
Crossplatform support is much more likely
Any defects discovered during the in the kernel port and maintenace will help with the Mac and Windows versions that lack this level of review; remember, the copyright holder does not loose copyright when using the GPL and can dual-licence or re-licence any code they have copyright to!
Knowing that the code will be seen, opening it encourages cleaning up and repairing the nasty parts -- or if it is not a port -- keeping it clean and better organized leading to fewer defects
There's not much of a benifit to binary-only modules for the vendor except;
They don't have to pull or replace code or binary parts that come from other companies (though this applies to few potential modules)
Likely faster to get an initial version out since there is no requirement for code review to be "accepted" (no acceptance process)
If the code is too messy, there's no need to clean it up so others can figure out what's going on or to avoid embarasment
Imagine a future where you install your core Linux kernel, then download a ton of different binary modules from different websites, have to hunt in the forums to mix-and-match the right versions, and end up having bugs nobody won't fix ? Think about it, that's what you want when you allow "pragmatism".
Hey! That would make Windows user feel right at home! LET'S DO IT!!!! (leaps behind flame-proof barrier)
Example, I remember at one CS program, the OS class was 9 weeks of learning how to _use_ Microsoft Windows.
Sorry, I don't believe it...though I'm willing to be swayed if you have details. Links or keywords to start a search would be ideal, though I can't think of a way to find this if it does exist without spending a couple hours.
I strongly feel that programming is a creative process, and anyone that describes it as a low-end job, does noet knows what programming is.
[blinks] HEY! Son-of-a-gun! That sounds like the programmers I'm working with right now!
(Ever want to re-write the programs someone else created...just to save yourself some time? Yep, it's that bad. All I can say, this is the worst group I've EVER delt with. The rest were creative professionals like you describe.)
Bioinformatics, wireless technologies, AI, robotics, there are so many fields which are budding. So many opportunites. Why do we have to look back at the financial software jobs that went away? We have much more interesting projects to be done.
Just the types of tasks that most programmers can't wrap thier brains around. Not that is unexpected or a bad thing over all.
Look at it this way: would you rather have the wristwatch that is hand crafted to perfection, works better, and will last forever, or would you rather buy the watch that came off of the assembly line, always loses time, and will break on you in a year or two?
Your analogy needs work. If real watches were inserted in your theoretical example, your point would be devistated.
I doubt you'll see native Exchange support, though you might want to check to see if POP & SMPT are used for your mail servers.
NOTE: Personally, I've been told where I am that there was no POP and SMPT access...even after repeated requests. The admin even went as far as to say it was corporate policy not to support POP or SMPT. They lied. Just plug the server settings in and see what happens. If that fails, try another similar address.
A request from IT to the user (developer or not) for a written reason before or after the installation would handle most situations. People that aren't that serious about a program will not write up anything.
That said, my preference is to;
Deny few people the write to install what they wish.
Put all on notice that some specific software isn't allowed and will be removed.
Put all on notice that anything that can't be justified may also be removed.
At work treat people like adults and expect them to do the right thing with little oversight. Adults at work aren't drinking buddies, so they aren't pals and should be held responsible when necessary.
No. Your reponsibility is with your immediate supervisor.... If you don't follow your immediate supervisor (with the obvious conditions, its not obviously damaging etc) then I would get rid of you in a second.
Yes and no. Yes, if the supervisor is competent they will make reasonable compromises. No, if they are just making things worse; no if they don't understand or care about process ever.
I am not suggesting that insubordination should be the default, or to be done quickly or frequently; no need to be rude or disrespectful. Work toward a sane process, and correct the dammage caused by ignoring process...maybe the supervisor will see the value?
It often takes many months to pull people -- including supervisors who should know better -- toward better methods. It's not futile.
An example of this is if a user asks you for an email account he wants for personal use. Your responsibility is to the user or the process set up?
Email account first, with an eye toward fixing any issues in the immediate setup. The security and policy issues with a personal use mail account are minimal.
They can't contend with all they have before them and thus adopt a horrible attitude.
Same happens in the corporate world.
One "solution" is to simplify as much as possible, though to do so with a process in mind -- not a specific product. This makes an impossible job simpler; it's still damn difficult, though.
Tip: Don't install any unneeded software and remove as much as possible from the default installations. Analysis tools can be used to determine what is running or is exposed (examples: Dependency Walker, Nessus). When in doubt, remove it and test for breakage. It's amazing how little is actually needed.
Almost every coding project is unique but in a commercial enviroment managers do force 'proven' textbook development methology onto projects regardless of suitability. To say nothing of the passionate flame wars OSS developers get involved in to argue about what's best for the program, try doing that on a commercial project!
True. There has to be some flexibility in methodoligies. Strict ones like SEI-CMM are often abused to get a check box on a contact's terms, though the methodologies themselves (when not abused) are quite practical.
Many OSS projects follow the spirit of the method and if were analyzed, I'm sure would be at or above the majority of private corporate projects.
I work to get payed, if that means I have to write sub-standard code to stay employed then so be it, noone outside the company sees the source code anyway. Working on projects in my free time, I try to write the highest quality code because it's going to be publicly availiable with my name on it for any number of potential employers to look at.
Point taken. In OSS, there isn't necessarily a need for others to love what you do or get thrilled about it. Some do need that, just like an atta-boy at work does make a difference if it's genuine and you respect the person giving the complement.
In either situation, after a while, it doesn't matter what others think since you know if you are any good.
I've noticed that 5 years ago, someone was always designated as the CM. Now, nobody is.
Maybe the problems with keeping development, deployment, and systems administration in sync would be helped by that level of glue.
The result would be that the fragmented systems administration level would be simplified since they wouldn't have to deal with configuration issues except where they impacted... well... systems administration.
Slashdot Mirror
I can compile kernels, but I'm not a kernel hacker. For the most part, I don't compile kernels I use the binaries.
For a promo shot, the same theme should be used, but this has to do with polish on the web site and nothing to do with polish on the app itself.
Thanks! I'm getting login verification errors using IMAP with NTLM / SPA authentication (required for Exchange?), though there are some notes on this and it looks 'solveable'.
I'm with you. I don't get the complaint except that he doesn't like how Linux implements SCSI. He seems really annoyed, though I don't understand the technical nature of his complaint.
That's not insightful, it's funny.
On a serious note, I've used the OSS modules for 5+ years, and it's worked well for me. Alsa is quite nice and I'm glad to see it as the default in the kernel now, though OSS is not unreliable by a long shot.
Joerg has complained about Linux for years (4? +5?), and generally perfers the SCSI subsystem in Solaris.
If you like card games, try this or this.
Linus himself says very little on the whole binary vs. source module issue.
The concensus on the list is that since Linux is licenced under the GPL it is up to the maker of binary-only modules to support them. The kernel and modules are designed to be a single unit, and compiled as a set. That means that when the kernel changes, the modules are changed as well -- sometimes not just the entry points, but also the internal APIs. Extentions to Linux should be in user space, not in the kernel. If a module needs to be in the kernel, the mainline kernel developers aren't going to bother working on someone else's code if they won't show the code!
This is discussed multiple times on the Linux kernel mailing list.
The manufacturer is selling hardware. Anything they want to protect from being exposed in the module means little to other hardware companies who have competent developers. The details of how the hardware is controlled and any setup and tables can be discovered using the Windows drivers and debuggers.
Contrary example: In Nvidia's case, they don't own everything they ship so unless they convince other companies to opening those parts (unlikely) Nvidia has to either drop those parts or replace them.
The motivations of different companies are important. Server-grade hardware companies fall all over themselves supporting Linux in the main kernel source tree. If Linux becomes popular on the desktop -- even if modestly so -- the kernel modules that support desktop software will likely be open. Nvidia might even change (though this is speculation on my part).
A few plusses just for maintenance come to mind, there are likely more for maintenance and other reasons such as good PR;
There's not much of a benifit to binary-only modules for the vendor except;
Hey! That would make Windows user feel right at home! LET'S DO IT!!!! (leaps behind flame-proof barrier)
Sorry, I don't believe it...though I'm willing to be swayed if you have details. Links or keywords to start a search would be ideal, though I can't think of a way to find this if it does exist without spending a couple hours.
Kinda reminds me of the car companies, let alone the computer companies. Where did your Intel chip get produced?
[blinks] HEY! Son-of-a-gun! That sounds like the programmers I'm working with right now!
(Ever want to re-write the programs someone else created...just to save yourself some time? Yep, it's that bad. All I can say, this is the worst group I've EVER delt with. The rest were creative professionals like you describe.)
Just the types of tasks that most programmers can't wrap thier brains around. Not that is unexpected or a bad thing over all.
Your analogy needs work. If real watches were inserted in your theoretical example, your point would be devistated.
NOTE: Personally, I've been told where I am that there was no POP and SMPT access...even after repeated requests. The admin even went as far as to say it was corporate policy not to support POP or SMPT. They lied. Just plug the server settings in and see what happens. If that fails, try another similar address.
Grrrr... change "write" to "right". It's getting late.
That said, my preference is to;
Deny few people the write to install what they wish.
Put all on notice that some specific software isn't allowed and will be removed.
Put all on notice that anything that can't be justified may also be removed.
At work treat people like adults and expect them to do the right thing with little oversight. Adults at work aren't drinking buddies, so they aren't pals and should be held responsible when necessary.
Yes and no. Yes, if the supervisor is competent they will make reasonable compromises. No, if they are just making things worse; no if they don't understand or care about process ever.
I am not suggesting that insubordination should be the default, or to be done quickly or frequently; no need to be rude or disrespectful. Work toward a sane process, and correct the dammage caused by ignoring process...maybe the supervisor will see the value?
It often takes many months to pull people -- including supervisors who should know better -- toward better methods. It's not futile.
An example of this is if a user asks you for an email account he wants for personal use. Your responsibility is to the user or the process set up?
Email account first, with an eye toward fixing any issues in the immediate setup. The security and policy issues with a personal use mail account are minimal.
Same happens in the corporate world.
One "solution" is to simplify as much as possible, though to do so with a process in mind -- not a specific product. This makes an impossible job simpler; it's still damn difficult, though.
True. There has to be some flexibility in methodoligies. Strict ones like SEI-CMM are often abused to get a check box on a contact's terms, though the methodologies themselves (when not abused) are quite practical.
Many OSS projects follow the spirit of the method and if were analyzed, I'm sure would be at or above the majority of private corporate projects.
Point taken. In OSS, there isn't necessarily a need for others to love what you do or get thrilled about it. Some do need that, just like an atta-boy at work does make a difference if it's genuine and you respect the person giving the complement.
In either situation, after a while, it doesn't matter what others think since you know if you are any good.
Maybe the problems with keeping development, deployment, and systems administration in sync would be helped by that level of glue.
The result would be that the fragmented systems administration level would be simplified since they wouldn't have to deal with configuration issues except where they impacted ... well ... systems administration.
On the other hand, there are some damn lame admins out there, so maybe it makes sense.
Agreed on formulas...though giving up and always winging it isn't very smart either. (IMNSHO)