How do you think big companies with thousands of desktops in multiple domains push out changes to the right machines and restrict shared filesystems to particular groups and delegate certain administration to local admins and create mailboxes and keep all those machines and all of those accounts organized and maintained?
Most people are utterly clueless about how Windows is *really* used in large organizations. They assume it's like their PCs at their home with a "server" in their basement. They've never thought about security policy, they don't understand how an ACL and unix permissions are semantically different, they don't know what Kerberos is and they think LDAP is an authentication service. When maintaining a few hundred PCs for a bunch of brokers or a design firm or a government organization a slew of Windows tools and services come into play that Linux simply does not have.
The fact is, Linux and Windows are not interchangeable and should not even be compared. Linux's strength is it's flexibility and simplicity. It's the flatbed truck of operating systems. If you want to run some web thing, a Java app or Oracle, Linux is the way to go. The strength of Windows is it's integration. It's not customizable and as such everyone's setup is the same so everything works easily with everything else. You could write a.NET script to collect information about a mailbox, generate a report and put the XLS on a shared drive *and it would work equally well on every Windows network*.
Incidentally, if you think I'm a Windows fanboy, as a programmer I use Linux as my desktop 100% of the time. I only use Windows as necessary to test my code (I write Linux / Windows integration software).
Ok, go ahead and mod me down now, I'm on the record.
This might be obvious, but take a close look at the authors of the article:
Dr. Robert B.K. Dewar, AdaCore Inc. (President) Dr. Edmond Schonberg, AdaCore Inc. (Vice President).
The article by some weird coincidence slams Java and praises Ada.
Salt, please...
I tooks some CS at NYU just for kicks. Dewar wrote the i386 'debug.exe' program we used for learning assembler. He wrote it in Cobol!
Personally I feel the only really important language to teach in CS courses is assember. That's what gives you the understanding of how the computer really works. After that, C is easy.
Also, CS has very little to do with programming. In fact, I think CS professors are usually pretty bad programmers. And with NYU being a heavy theory school this topic is a little ironic.
Finally, I think Java is a very good language. The libraries are getting horribly bloated and some things like thread primatives are messed up but the language itself is very nice.
The difference is that my sister really likes the look of her new slick white macbook (almost as much as her new slick black iPhone) and it will look even better when she takes it to classes at those cool stores.
I don't care so much about yum vs. apt but I do think RPM is better than dpkg. With RPM it is easier to query packages, recompile packages from.src.rpm and force things if necessary. With dpkg querying packages and their deps is harder, there are no source packages which makes recompiling odd, and you cannot install a package that is not specifically built for the distro. Those sort of things become very important when you're trying to extend the life of an install as support for it starts to dry up. I've use both Debian based systems and RPM based systems for a long time and after all of these years I think I have to pick RPM. In truth they're all a little lame. RPM is just less lame. Yeah, apt was the first to automate package installation. But these days that functionality is a given.
The typical sensors in airplane tanks are capacitive dielectric guages. These can easily be made to run on microwatts of signal, not enough to cause ignition.
Now I know you're not an engineer thus probably shouldn't be making such a bold analysis. The current on the wire doesn't matter. It still conducts electricity. If that wire is bundled with another higher voltage wire and there's a short you can get an arc. That's happened before which is probably the trust behind the product.
If you literally cut and paste or copy something verbatum from somewhere, whether it be a poem or code, even in a public forum, technically it's implicitly copyrighted by the author.
However, in practice, if the intent of the author was to share the code with other developers as reciprocation for assistance in the forum, code masterbation, karma, whatever, the implicit copyright is weak. IANAL but I don't see how any court could ever find the copier at fault and really you shouldn't either.
200 lines of web code is not a significant part of your company's intellectual property. Be flattered, move on and keep hitting the pavement like everyone else.
Maybe they do not help in deterring crime but I wonder if they help get convictions. If you catch a purse napper it's hard for him to say that he just found it in the garbage if they have him on video forcefully taking it from her.
This is a highly twisted version of reality. The "undefined field" you mention is the authorization-data field in Kerberos tickets. That field is designed to contain application specific data such as groups and information about the user and that is precisely what MS used it for. No foul there. The structure they put in the authorization-data field is called the Privileged Attribute Certificate (PAC). The problem was that MS stated that the PAC was proprietary and that no one could implement it. I'm not sure which court breif you're talking about but I'm pretty sure the "big falling out" was over the IP claim on data in the Kerberos tickets wrt the PAC. MS reversed it's position. Information on the PAC is freely available on their website:
Personally I feel strongly that companies should be required to make more information available about interprocess communication used in applications that have a significant market share (e.g. MS office files, AD directory replication semantics, workstation management RPCs, etc). However, I also find it very frustrating to see people misrepresenting the truth. The truth is in your favor so by mis-represeting it you're only hurting yourselves.
You mean the doc that came as a self-extracting archive that presented an EULA that looked suspiciously like an NDA? A license that was eventually dropped after much screaming from the rest of the computing world in the direction of Seattle?
When it was first released they tried to claim no one could implement it. But that was knocked down to an un-naturally long copyright statement and a copyright statement only covers the content of the document / page. They could try to claim otherwise (e.g. like SCO tried with errno.h) but copyright has no impact on implementing what is described (sort of like how you can study GPL code and implement it elsewhere - you just can't copy and paste anything).
The document you're talking about was the CIFS spec wrapped in a Windows help file. That was just a feeble attempt to quell protesters asking for protocol documentation but that document's content had been available for many years so the overall effect was that they just annoyed the hell out of everyone by taking an existing document and sticking an EULA in it. That whole escapade was doomed to backfire. It was quite amusing really.
Long ago, people were all upset when Microsoft did the ole embrace and extend thing with Kerberos. I haven't heard much about that for years. Has it been a problem for anyone? Will the Kerberos consortium take whatever Microsoft did into account so as not to break what other people have done to work with and around Microsoft?
MS and the MIT Kerberos crowd get along just fine. I believe the things MS did are generally thought of as good. Some are starting to make it into the Kerberos distros (e.g. I think Heimdal has support for constrained delegation). The PAC business was a little overblown. The Samba guys were able to figure out how to sign the PAC from the doc MS provided and with some carefull network analysis. Of course the Samba guys are not happy overall. I don't know if they have a problem with their Kerberos code but other modes of communication and the semantics to go with are not adequately documented.
My from-the-hip guess is that MIT has realized that they're a)dependent on Kerberos and b)nobody else uses it, so they need to generate some noise, make some unfounded claims, and hope to get some other people onboard. "Used in the enterprise"? Bull...
FYI: Kerberos is the standard authentication protocol used on just about every enterprise network on the planet. All Windows clients that are members of an Active Directory domain use Kerberos to authenticate with fileservers, web services, LDAP servers and just about anything else that has domain credentials. That's probably 80% of Enterprise users alone. And the rest are probably using NFS which is rapidly moving to Kerberos authn' for everything.
... on big servers but not on just about anything else. Solaris is the flat-bed 18 wheeler of OSs. It scales well are machines with a lot of processors, it has good supported drivers for "big" hardware like fiber drive arrays, there's good support from Sun and third party providers and, most importantly from a Linux prespecitive, it will be easy to GNU-ize the system to get "GNU/Solaris". But it will be very hard to supplant Linux on Pee-Cees. If you think you have problems with wireless and suspending on your laptop you can forget running Solaris on it. With Solaris you have to buy the hardware to fit the OS whereas Linux is the best *nix for commodity hardware.
Whenever I see a story like this I'm always curious as to who is really at fault.
The question is, what does the broadcast flag *do* and should servers be required to implement it?
From some web page:
The "broadcast flag": DHCP includes a way in which client implementations unable to receive a packet with a specific IP address can ask the server or relay agent to use the broadcast IP address in the replies (a "flag" set by the client in the requests). The definition of DHCP states that implementations "should" honor this flag, but it doesn't say they "must". Some Microsoft TCP/IP implementations used this flag, which meant in practical terms, relay agents and servers had to implement it. A number of BOOTP-relay-agent implementations (e.g. in routers) handled DHCP just fine except for the need for this feature, thus they announced new versions stated to handle DHCP.
So servers "should" implement it but are not required to. But now there are a few obvious questions:
1. What are the benifits of using broadcast over unicast? If the client can accept unicast and unicast is somehow "better" then why are MS client's sending the broadcast flag in the first place?
2. If servers are not required to support the broadcast flag, is there a alternative protocol sequence that will allow clients that desire the broadcast behavior to successfully obtain an IP with the server? If the purpose of the broadcast flag is for clients that incapible of receiving unicast responses, then it seems that client could not possible negotiate successfully with a server that does not support the broadcast flag.
3. Ultimately, the question will be, should DHCP server implement the broadcast flag?
This is where you need to get philosophical. Is vmkernel using kernel routines because it wants to or because it *has* to. Meaning, is vmkernel using the kernel routines to do all the vm related work that they could otherwise do equally well with their own code? Or is vmkernel using kernel routines that it MUST use to interface with the host to do I/O, implement the abstract syscalls, etc? Considering ESX runs on a number of platforms my *guess* is they probably favor the later. If they did just what they needed to do to make their product run on Linux then I don't see why anyone should have a problem with that. And if the GPL is not compatible with that then I would advocate adding a clause to the license to provide for these scenarios.
Linux supports ACLs fine, setfacl is what you use to change ACLs and there are UIs for ACLs. Samba supports ACLs, and in a cross compatible with Windows way too.
Typical hair splitting non-sense. My point about ACLs was that a Linux desktop user cannot share documents on the network. That would require authentication and authorization such that the user's identity and groups are used by the remote server to make access control decisions. Although technically possible it is very difficult to setup and administer.
To a kernel, people can be represented by a small number. Windows kernel works the same way. File sharing and so on work outside the kernel and do it fine. There's no reason the kernel can't internally think of the users as a small number when doing filesystem permission checks. The filesharing application will translate this small number into a username or something else when dealing with remote logins or ACLs.
You are so misguided. Windows SIDs have domain part which is specific to the domain controller on which they were created. The relative part identifies the specific account within the domain. An ACL is a list of SIDs and corresponding access masks. The Windows kernel takes the user's SID and compares it to the SIDs in the ACL when making access control checks. Linux has no concept of a domain component so everything must be mapped to local UIDs. That is very clumsey but no one cares because *nix machines are application platforms so domain membership is not terribly important. Again, the whole point is that trying to share content between desktop users with ACLs is not practical.
This is where I think Linux has more of a chance. It's completely centrally manageable, lightweight, open and free. It can be customised completely to the needs of the corporation and can be configured to work extremely well on any given hardware with a selection of apps that cooperate properly together and are heavily tested.
This proves without a doubt that you have absolutely no clue what you're talking about. Corporate types don't want "open", "free", or "customised". They want to plug it in, turn it on, and start cutting and pasting and sharing documents and killing stuff with ctrl-alt-del. They don't want to setup ldap such that it replicates kerberos keys in just such a way and make sure they're using such and such filesystem so that ACLs work, blah, blah, blah. If some middle manager saw that going on they would have a heart attack right there on the spot thinking about the liabilites involved. If you ever worked in an office environment you would know this (or you know it but you just don't want to believe it because it crushes your hope for a Linux desktop).
Setting up everything you need for Linux desktop clients in a large Intranet environment is very difficult and the reason is that all of the components are developed independently from one another and as such they each need configuration to work with the other.
Advocating Linux for the desktop only makes it harder for Linux to make it where it deserves to succeed which is in the data center. Your fanatic retoric is doing harm to the credablity of Linux in intranet environments. Please stop.
Desktop Linux, or any *nix desktop for that matter, is at a serious disadvantage to Windows. Anyone who has worked in a big all-MS shop knows that people are doing a lot of stuff like:
Cutting and pasting fragments of data from one office app to another
Accessing files on shared drives restricted to certain groups
Killing errant applications with the Task Manager via ctrl-alt-del
These things all have something in common that the *nix desktop does not have and will likely never have. They all are features that transcend different components of the desktop, OS middle-layer, kernel and network services.
Cutting and pasting a table from Excel into Word requires that both applications agree on what the format of that data will be. Dispite the fact that early MS software was buggy, OLE delegated the responsibility of encoding and decoding clip board data and that was the right way to solve the problem. But *nix applications are developed entiresly independantly of one another and of course X Windows says nothing about what is in the clip board (actually what's really confusing is that there's actually two clip boards in X - the text one when you highlight something and the regular one that not many applications use). Anyway, the bottom line is that if you want to cut something from gnumeric and past it into OOo writer, it's not going to work. To solve this problem X needs a "com"unication layer that will allow one application to invoke routines in another so as to properly translate data in the clip board. Trying to get X, gnumeric and OOo developers to coordinate on such a project is rediculously hopeless.
Accessing files on shared drives may sound easy - "just use Samba or NFS" you say? Ha. Linux security works at the OS level. If you're root on one system and you access a filesystem on another system over NFS you can modify files owned by root without having authenticated. That's a HUGE security flaw and it's been that way forever. NFSv4 is trying to remedy some of these problems with GSSAPI authentication, UID mapping and so on but NFSv4 isn't anywhere near the "just works" stage and won't be for a long long time since you need a filesystem with more sophisticated extended attribute controls. That brings me to the related problem of groups which are still old-skool course quantized one group per file (yes I know it was elegant but it's just not going to work anymore). In a large IntrAnet environment you must have ACLs that support inheritance and even if you do have that you have to have decent tools to manage them. Admins have enough trouble understanding ACLs there's no way the average MircroSofty is going to using xattr on the commandline. So you see this problem transcends the security infrastructure from the KDCs on the network, to how users are represented in the kernel and in filesystems. Now imagine trying to get some Kernel developers who believe everyone can be represented by a small number unique to the local system to think about how ACL entries on another system and how to quickly perform access checks on ACLs in the kernel. Good luck with that.
One of the best features of Windows is the Task Manager. When you press Ctrl-Alt-Del on Windows a special routine runs in the kernel. The Windowing system is completely stopped in it's tracks by this routine. Special light weight windowing code in the kernel pops up and the user can select processes for a number of actions the most important of which is to simply kill things. The bottom line is that whey you kill something it's *really* killed. Dead. No "zombies". No hanging. It's just gone. Again you can see why this feature is like the others. It's code that trancends the Windowing system and kernel. Most serious Linux installs don't even run a desktop let alone X windows (and that's the way it should be). So 99% of Linux Kernel devs don't give a rat's tail about some desktop process control feature. As far as there concerned ctrl-alt-del still means "reboot" and they'll be damned
For those who may not fully understand what SELinux actually does, let me give you an example.
With SELinux enabled, by detault Apache will be prevented from accessing files other than those of very basic web apps, it cannot open sockets to other hosts, etc.
For IntErnet applications this is quite reasonable and with the machine on the most hostile network around you really should use SELinux. It won't stop a break in but it can seriously curtail the effects of one.
For an IntrAnet application that is trying to write to custom log files and talk to LDAP servers and such, SELinux is not going to let you do that. At this point you have two choices - 1) tweek SELinux properties to allow only the specific functionality required by the application or 2) disable SELinux for that entire application. Considering an IntrAnet affords some physical protection, SELinux is less important in that environment and therefore, in this scenario, if you're really not savvy with SELinux and you don't have the time to get into it, I recommend just disabling it for entire application using it.
For example, to disable SELinux just for Apache you do:
# setsebool -P httpd_disable_trans 1 # service httpd restart
Note that SELinux uses db files that remember these changes so they will persist across reboots and there are no config files to edit. It's a nice system because it's easy to add these commands to install scripts and such.
So don't get bent about SELinux. Learn enough to disable it for specific apps and then turn it on all over. Keep an eye on the log files. If SELinux is stopping access to things by apps it will report it in the log file. Then determine if the app should be doing that and if so disable SELinux just for that app.
Or hire someone for minimum wage to waste their time.
And make the requirements for participation insane.
1) All resumes must be submitted in encapsulated PostScript. 2) We need a Java Programmer with 27 years of experience. 3) If they every do find someone that qualifies, tell them the position was just filled. 3) You must answer the daily riddle before anyone will accept your call. 5)...
... that 435mb you're talking about includes a lot of other software that isn't necessary. and yes, you can install just the drivers if you want to
I don't have to do research, I just installed HP drivers for an all-in-one a few hours ago and there was NO such option. There were two radio buttons. One said "full" or something like that and was 750MB of disk space required. The other option was 450MB. I saw no way to NOT install the imaging crud.
HP is a mess
on
The HP Way 2.0
·
· Score: 3, Interesting
Why does a printer driver require 435 MB of disk space (no really, you cannot install it otherwise) and take 30 minutes and a reboot to install?
This is one of those situations where a lot of higher-ups need to get the axe but of course they're not going to fire themselves. Same goes for Yahoo! with their over-AJAX-ified website overhaul.
... it seems as though the editors like to fuel the fire.
I totally agree. We really should be above this type of attack and just totally ignore this FUD. There's NO WAY they could bring this to a court. You can't sue somebody without telling them WHY! Utterly ridiculous. And WHO are they going to sue anyway?
But of course I read the comments and./ get's page impressions so...
Slashdot Mirror
How do you think big companies with thousands of desktops in multiple domains push out changes to the right machines and restrict shared filesystems to particular groups and delegate certain administration to local admins and create mailboxes and keep all those machines and all of those accounts organized and maintained?
.NET script to collect information about a mailbox, generate a report and put the XLS on a shared drive *and it would work equally well on every Windows network*.
Most people are utterly clueless about how Windows is *really* used in large organizations. They assume it's like their PCs at their home with a "server" in their basement. They've never thought about security policy, they don't understand how an ACL and unix permissions are semantically different, they don't know what Kerberos is and they think LDAP is an authentication service. When maintaining a few hundred PCs for a bunch of brokers or a design firm or a government organization a slew of Windows tools and services come into play that Linux simply does not have.
The fact is, Linux and Windows are not interchangeable and should not even be compared. Linux's strength is it's flexibility and simplicity. It's the flatbed truck of operating systems. If you want to run some web thing, a Java app or Oracle, Linux is the way to go. The strength of Windows is it's integration. It's not customizable and as such everyone's setup is the same so everything works easily with everything else. You could write a
Incidentally, if you think I'm a Windows fanboy, as a programmer I use Linux as my desktop 100% of the time. I only use Windows as necessary to test my code (I write Linux / Windows integration software).
Ok, go ahead and mod me down now, I'm on the record.
This might be obvious, but take a close look at the authors of the article:
Dr. Robert B.K. Dewar, AdaCore Inc. (President)
Dr. Edmond Schonberg, AdaCore Inc. (Vice President).
The article by some weird coincidence slams Java and praises Ada.
Salt, please...
I tooks some CS at NYU just for kicks. Dewar wrote the i386 'debug.exe' program we used for learning assembler. He wrote it in Cobol!
Personally I feel the only really important language to teach in CS courses is assember. That's what gives you the understanding of how the computer really works. After that, C is easy.
Also, CS has very little to do with programming. In fact, I think CS professors are usually pretty bad programmers. And with NYU being a heavy theory school this topic is a little ironic.
Finally, I think Java is a very good language. The libraries are getting horribly bloated and some things like thread primatives are messed up but the language itself is very nice.
The difference is that my sister really likes the look of her new slick white macbook (almost as much as her new slick black iPhone) and it will look even better when she takes it to classes at those cool stores.
Has yum improved that much to match apt? I doubt.
.src.rpm and force things if necessary. With dpkg querying packages and their deps is harder, there are no source packages which makes recompiling odd, and you cannot install a package that is not specifically built for the distro. Those sort of things become very important when you're trying to extend the life of an install as support for it starts to dry up. I've use both Debian based systems and RPM based systems for a long time and after all of these years I think I have to pick RPM. In truth they're all a little lame. RPM is just less lame. Yeah, apt was the first to automate package installation. But these days that functionality is a given.
I don't care so much about yum vs. apt but I do think RPM is better than dpkg. With RPM it is easier to query packages, recompile packages from
The typical sensors in airplane tanks are capacitive dielectric guages. These can easily be made to run on microwatts of signal, not enough to cause ignition.
Now I know you're not an engineer thus probably shouldn't be making such a bold analysis. The current on the wire doesn't matter. It still conducts electricity. If that wire is bundled with another higher voltage wire and there's a short you can get an arc. That's happened before which is probably the trust behind the product.
We've had these fluorescent cats in New Jersey for decades. No genetic modification necessary.
If you literally cut and paste or copy something verbatum from somewhere, whether it be a poem or code, even in a public forum, technically it's implicitly copyrighted by the author.
However, in practice, if the intent of the author was to share the code with other developers as reciprocation for assistance in the forum, code masterbation, karma, whatever, the implicit copyright is weak. IANAL but I don't see how any court could ever find the copier at fault and really you shouldn't either.
200 lines of web code is not a significant part of your company's intellectual property. Be flattered, move on and keep hitting the pavement like everyone else.
Maybe they do not help in deterring crime but I wonder if they help get convictions. If you catch a purse napper it's hard for him to say that he just found it in the garbage if they have him on video forcefully taking it from her.
This is a highly twisted version of reality. The "undefined field" you mention is the authorization-data field in Kerberos tickets. That field is designed to contain application specific data such as groups and information about the user and that is precisely what MS used it for. No foul there. The structure they put in the authorization-data field is called the Privileged Attribute Certificate (PAC). The problem was that MS stated that the PAC was proprietary and that no one could implement it. I'm not sure which court breif you're talking about but I'm pretty sure the "big falling out" was over the IP claim on data in the Kerberos tickets wrt the PAC. MS reversed it's position. Information on the PAC is freely available on their website:
http://msdn2.microsoft.com/en-us/library/aa302203.aspx
Personally I feel strongly that companies should be required to make more information available about interprocess communication used in applications that have a significant market share (e.g. MS office files, AD directory replication semantics, workstation management RPCs, etc). However, I also find it very frustrating to see people misrepresenting the truth. The truth is in your favor so by mis-represeting it you're only hurting yourselves.
You mean the doc that came as a self-extracting archive that presented an EULA that looked suspiciously like an NDA? A license that was eventually dropped after much screaming from the rest of the computing world in the direction of Seattle?
No, I mean this:
http://msdn2.microsoft.com/en-us/library/aa302203.aspx
When it was first released they tried to claim no one could implement it. But that was knocked down to an un-naturally long copyright statement and a copyright statement only covers the content of the document / page. They could try to claim otherwise (e.g. like SCO tried with errno.h) but copyright has no impact on implementing what is described (sort of like how you can study GPL code and implement it elsewhere - you just can't copy and paste anything).
The document you're talking about was the CIFS spec wrapped in a Windows help file. That was just a feeble attempt to quell protesters asking for protocol documentation but that document's content had been available for many years so the overall effect was that they just annoyed the hell out of everyone by taking an existing document and sticking an EULA in it. That whole escapade was doomed to backfire. It was quite amusing really.
Long ago, people were all upset when Microsoft did the ole embrace and extend thing with Kerberos. I haven't heard much about that for years. Has it been a problem for anyone? Will the Kerberos consortium take whatever Microsoft did into account so as not to break what other people have done to work with and around Microsoft?
MS and the MIT Kerberos crowd get along just fine. I believe the things MS did are generally thought of as good. Some are starting to make it into the Kerberos distros (e.g. I think Heimdal has support for constrained delegation). The PAC business was a little overblown. The Samba guys were able to figure out how to sign the PAC from the doc MS provided and with some carefull network analysis. Of course the Samba guys are not happy overall. I don't know if they have a problem with their Kerberos code but other modes of communication and the semantics to go with are not adequately documented.
My from-the-hip guess is that MIT has realized that they're a)dependent on Kerberos and b)nobody else uses it, so they need to generate some noise, make some unfounded claims, and hope to get some other people onboard. "Used in the enterprise"? Bull...
FYI: Kerberos is the standard authentication protocol used on just about every enterprise network on the planet. All Windows clients that are members of an Active Directory domain use Kerberos to authenticate with fileservers, web services, LDAP servers and just about anything else that has domain credentials. That's probably 80% of Enterprise users alone. And the rest are probably using NFS which is rapidly moving to Kerberos authn' for everything.
... on big servers but not on just about anything else. Solaris is the flat-bed 18 wheeler of OSs. It scales well are machines with a lot of processors, it has good supported drivers for "big" hardware like fiber drive arrays, there's good support from Sun and third party providers and, most importantly from a Linux prespecitive, it will be easy to GNU-ize the system to get "GNU/Solaris". But it will be very hard to supplant Linux on Pee-Cees. If you think you have problems with wireless and suspending on your laptop you can forget running Solaris on it. With Solaris you have to buy the hardware to fit the OS whereas Linux is the best *nix for commodity hardware.
Whenever I see a story like this I'm always curious as to who is really at fault.
The question is, what does the broadcast flag *do* and should servers be required to implement it?
From some web page:
The "broadcast flag": DHCP includes a way in which client implementations unable to receive a packet with a specific IP address can ask the server or relay agent to use the broadcast IP address in the replies (a "flag" set by the client in the requests). The definition of DHCP states that implementations "should" honor this flag, but it doesn't say they "must". Some Microsoft TCP/IP implementations used this flag, which meant in practical terms, relay agents and servers had to implement it. A number of BOOTP-relay-agent implementations (e.g. in routers) handled DHCP just fine except for the need for this feature, thus they announced new versions stated to handle DHCP.
So servers "should" implement it but are not required to. But now there are a few obvious questions:
1. What are the benifits of using broadcast over unicast? If the client can accept unicast and unicast is somehow "better" then why are MS client's sending the broadcast flag in the first place?
2. If servers are not required to support the broadcast flag, is there a alternative protocol sequence that will allow clients that desire the broadcast behavior to successfully obtain an IP with the server? If the purpose of the broadcast flag is for clients that incapible of receiving unicast responses, then it seems that client could not possible negotiate successfully with a server that does not support the broadcast flag.
3. Ultimately, the question will be, should DHCP server implement the broadcast flag?
This is where you need to get philosophical. Is vmkernel using kernel routines because it wants to or because it *has* to. Meaning, is vmkernel using the kernel routines to do all the vm related work that they could otherwise do equally well with their own code? Or is vmkernel using kernel routines that it MUST use to interface with the host to do I/O, implement the abstract syscalls, etc? Considering ESX runs on a number of platforms my *guess* is they probably favor the later. If they did just what they needed to do to make their product run on Linux then I don't see why anyone should have a problem with that. And if the GPL is not compatible with that then I would advocate adding a clause to the license to provide for these scenarios.
I wonder how affordable this is if it requires a 33 tesla magnet to run long enough for crystals to grow (weeks).
Linux supports ACLs fine, setfacl is what you use to change ACLs and there are UIs for ACLs. Samba supports ACLs, and in a cross compatible with Windows way too.
Typical hair splitting non-sense. My point about ACLs was that a Linux desktop user cannot share documents on the network. That would require authentication and authorization such that the user's identity and groups are used by the remote server to make access control decisions. Although technically possible it is very difficult to setup and administer.
To a kernel, people can be represented by a small number. Windows kernel works the same way. File sharing and so on work outside the kernel and do it fine. There's no reason the kernel can't internally think of the users as a small number when doing filesystem permission checks. The filesharing application will translate this small number into a username or something else when dealing with remote logins or ACLs.
You are so misguided. Windows SIDs have domain part which is specific to the domain controller on which they were created. The relative part identifies the specific account within the domain. An ACL is a list of SIDs and corresponding access masks. The Windows kernel takes the user's SID and compares it to the SIDs in the ACL when making access control checks. Linux has no concept of a domain component so everything must be mapped to local UIDs. That is very clumsey but no one cares because *nix machines are application platforms so domain membership is not terribly important. Again, the whole point is that trying to share content between desktop users with ACLs is not practical.
This is where I think Linux has more of a chance. It's completely centrally manageable, lightweight, open and free. It can be customised completely to the needs of the corporation and can be configured to work extremely well on any given hardware with a selection of apps that cooperate properly together and are heavily tested.
This proves without a doubt that you have absolutely no clue what you're talking about. Corporate types don't want "open", "free", or "customised". They want to plug it in, turn it on, and start cutting and pasting and sharing documents and killing stuff with ctrl-alt-del. They don't want to setup ldap such that it replicates kerberos keys in just such a way and make sure they're using such and such filesystem so that ACLs work, blah, blah, blah. If some middle manager saw that going on they would have a heart attack right there on the spot thinking about the liabilites involved. If you ever worked in an office environment you would know this (or you know it but you just don't want to believe it because it crushes your hope for a Linux desktop).
Setting up everything you need for Linux desktop clients in a large Intranet environment is very difficult and the reason is that all of the components are developed independently from one another and as such they each need configuration to work with the other.
Advocating Linux for the desktop only makes it harder for Linux to make it where it deserves to succeed which is in the data center. Your fanatic retoric is doing harm to the credablity of Linux in intranet environments. Please stop.
Desktop Linux, or any *nix desktop for that matter, is at a serious disadvantage to Windows. Anyone who has worked in a big all-MS shop knows that people are doing a lot of stuff like:
Cutting and pasting fragments of data from one office app to another
Accessing files on shared drives restricted to certain groups
Killing errant applications with the Task Manager via ctrl-alt-del
These things all have something in common that the *nix desktop does not have and will likely never have. They all are features that transcend different components of the desktop, OS middle-layer, kernel and network services.
Cutting and pasting a table from Excel into Word requires that both applications agree on what the format of that data will be. Dispite the fact that early MS software was buggy, OLE delegated the responsibility of encoding and decoding clip board data and that was the right way to solve the problem. But *nix applications are developed entiresly independantly of one another and of course X Windows says nothing about what is in the clip board (actually what's really confusing is that there's actually two clip boards in X - the text one when you highlight something and the regular one that not many applications use). Anyway, the bottom line is that if you want to cut something from gnumeric and past it into OOo writer, it's not going to work. To solve this problem X needs a "com"unication layer that will allow one application to invoke routines in another so as to properly translate data in the clip board. Trying to get X, gnumeric and OOo developers to coordinate on such a project is rediculously hopeless.
Accessing files on shared drives may sound easy - "just use Samba or NFS" you say? Ha. Linux security works at the OS level. If you're root on one system and you access a filesystem on another system over NFS you can modify files owned by root without having authenticated. That's a HUGE security flaw and it's been that way forever. NFSv4 is trying to remedy some of these problems with GSSAPI authentication, UID mapping and so on but NFSv4 isn't anywhere near the "just works" stage and won't be for a long long time since you need a filesystem with more sophisticated extended attribute controls. That brings me to the related problem of groups which are still old-skool course quantized one group per file (yes I know it was elegant but it's just not going to work anymore). In a large IntrAnet environment you must have ACLs that support inheritance and even if you do have that you have to have decent tools to manage them. Admins have enough trouble understanding ACLs there's no way the average MircroSofty is going to using xattr on the commandline. So you see this problem transcends the security infrastructure from the KDCs on the network, to how users are represented in the kernel and in filesystems. Now imagine trying to get some Kernel developers who believe everyone can be represented by a small number unique to the local system to think about how ACL entries on another system and how to quickly perform access checks on ACLs in the kernel. Good luck with that.
One of the best features of Windows is the Task Manager. When you press Ctrl-Alt-Del on Windows a special routine runs in the kernel. The Windowing system is completely stopped in it's tracks by this routine. Special light weight windowing code in the kernel pops up and the user can select processes for a number of actions the most important of which is to simply kill things. The bottom line is that whey you kill something it's *really* killed. Dead. No "zombies". No hanging. It's just gone. Again you can see why this feature is like the others. It's code that trancends the Windowing system and kernel. Most serious Linux installs don't even run a desktop let alone X windows (and that's the way it should be). So 99% of Linux Kernel devs don't give a rat's tail about some desktop process control feature. As far as there concerned ctrl-alt-del still means "reboot" and they'll be damned
That is what the title should read. There's no "cure" if it's not a disease.
If fearlessness was advantageous everone would have it. When a caveman comes after you with a stick trying to skewer your ass you should run.
For those who may not fully understand what SELinux actually does, let me give you an example.
With SELinux enabled, by detault Apache will be prevented from accessing files other than those of very basic web apps, it cannot open sockets to other hosts, etc.
For IntErnet applications this is quite reasonable and with the machine on the most hostile network around you really should use SELinux. It won't stop a break in but it can seriously curtail the effects of one.
For an IntrAnet application that is trying to write to custom log files and talk to LDAP servers and such, SELinux is not going to let you do that. At this point you have two choices - 1) tweek SELinux properties to allow only the specific functionality required by the application or 2) disable SELinux for that entire application. Considering an IntrAnet affords some physical protection, SELinux is less important in that environment and therefore, in this scenario, if you're really not savvy with SELinux and you don't have the time to get into it, I recommend just disabling it for entire application using it.
For example, to disable SELinux just for Apache you do:
# setsebool -P httpd_disable_trans 1
# service httpd restart
Note that SELinux uses db files that remember these changes so they will persist across reboots and there are no config files to edit. It's a nice system because it's easy to add these commands to install scripts and such.
So don't get bent about SELinux. Learn enough to disable it for specific apps and then turn it on all over. Keep an eye on the log files. If SELinux is stopping access to things by apps it will report it in the log file. Then determine if the app should be doing that and if so disable SELinux just for that app.
Or hire someone for minimum wage to waste their time.
...
And make the requirements for participation insane.
1) All resumes must be submitted in encapsulated PostScript.
2) We need a Java Programmer with 27 years of experience.
3) If they every do find someone that qualifies, tell them the position was just filled.
3) You must answer the daily riddle before anyone will accept your call.
5)
... that 435mb you're talking about includes a lot of other software that isn't necessary. and yes, you can install just the drivers if you want to
I don't have to do research, I just installed HP drivers for an all-in-one a few hours ago and there was NO such option. There were two radio buttons. One said "full" or something like that and was 750MB of disk space required. The other option was 450MB. I saw no way to NOT install the imaging crud.
Why does a printer driver require 435 MB of disk space (no really, you cannot install it otherwise) and take 30 minutes and a reboot to install?
This is one of those situations where a lot of higher-ups need to get the axe but of course they're not going to fire themselves. Same goes for Yahoo! with their over-AJAX-ified website overhaul.
I haven't read beyond the headline but this is just screaming "HOAX!".
... it seems as though the editors like to fuel the fire.
./ get's page impressions so ...
I totally agree. We really should be above this type of attack and just totally ignore this FUD. There's NO WAY they could bring this to a court. You can't sue somebody without telling them WHY! Utterly ridiculous. And WHO are they going to sue anyway?
But of course I read the comments and