Free is nice, but that's no guarntee that it will work properly. An operating system update is much more invasive than a single package. How much more memory does the current version require? How much more disk space? Does FC2 even support a direct upgrade from RH6? Once again, big hammer for (should be) small problem.
By Win32 I mean everything that a Windows application calls or passes control to that isn't in the kernel.
This definition is over-reaching. There are user mode processes that do not depend on or are even aware of Win32. How about the Session Manager (init process)? It does not depend on Win32, does not run in kernel mode, and yet provides services from the "\SmApiPort" LPC port. What about other intrinisic subsystems like the Security Accounts Manager, the Local Security Authority, the Event Log, and user mode Plug & Play? There are many other services that use Win32 only for the service control interface, maintained by services.exe and the Win32 library interface. They don't care about the Win32 server's internal state, and so cannot be corrupted from it. These are services that have zero windows, the only Win32 specific message destination; they only link to advapi.dll and kernel32.dll, whose functions are handled by the kernel, not the Win32 server. In fact, according to Microsoft guidelines services are never supposed to create windows, exactly because it could be a security problem.
It still maintains shared state that can lead to security violations if it's corrupted, so that internal state has to be considered part of the trust boundary.
Since the Win32 server is a trusted component, taking control of it would mean control of the system. Are you saying that corruption of Win32's state is unavoidable due to its design, or that Win32 adds too much attack area?
Also, the shared memory extension to X is a performance enhancement. X will run over any communication channel that provides a single reliable buffered stream.
Looking through \BaseNamedObjects, there are exactly 0 shared memory "section" objects that are world-writable. There are 5 that only me personally can read and write to, 3 accessable to SYSTEM and Administrators, and several read-only to everyone. (excluding the sections made by Cygwin; insecure sections made by it to maintain state are a long-known problem) It's possible that there are some insecure sections that are being duplicated among processes (I doubt it as shared objects almost always have names, so they can be found easily: some process has to personally duplicate a handle for you otherwise), but I'm not about to check every unnamed section; perfmon tells me that there are 4171 section objects, more than any other type. I get the feeling that sections are either used to advertise public information, exchange state between processes in the same security context (like the sections accessible only to me), as a private channel between two processes (I assume data there is checked like any other source), or to memory-map files. They aren't used to store common state information, far as I can tell. That's done in private memory in the service's server process.
Linux is a particularly profligate implementation of UNIX, yes, but I suspect that count's significantly inflated.
In the kernel source, under include/linux/syscalls.h, I counted the number of asmlinkage functions, and got 268. From the filename and contents, I assume this defines the syscall entrypoints. To get XP's syscall count, I counted the number of Nt* functions exported from ntdll.dll, which is 285. If you have a better way to count them...
It's all part of the same distinction. If your communication is over a buffered stream, you don't need to know what's at the other end.
Windows has generic pipes, too. The console, pipes, sockets, anything you can use CreateFile on can all be accessed with the
Rather obviously, configuration and compilation ensures compatibility with the existing installation.
Does it? All code is not portable. Not across architectures, not across libraries, not across filesystem layout styles... They can be, but compiling from source certainly does not ensure compatibility.
Different distros don't even use the same kernel. Many apply their own patches to the kernel. If you need packages prepared for you, use Mandrake, and you can request RPMs for your favorite apps.
So what if they don't use the same kernel. What about application packages that use POSIX and don't care about the kernel? Why should I have to wait for Mandrake, even when I'm using Mandrake, to make a package when Debian already has one for the app I want? Why is there no standard?
Nobody is forcing you to use Linux or any particular distro.
What should I do when two rare packages are available exclusively on different distros? By choosing one, I am forced to only use packages from that distro and no others.
If you are so bothered by the lack of a package for your favorite app, then why not give something back and put an RPM together?
That is a good point, but it's a bad solution to the root problem of gross package incompatibility. It should be solved at the problem's source instead of forcing each user to come up with their own workaround.
But here's a few services that would I believe would be kernel components in UNIX.
Plug and Play.
Server, Workstation.
HID Input service, et al.
Plug and Play is implemented in two parts: an executive service (in kernel mode) that communicates with drivers, enumerates busses and loads drivers for devices that are already installed, and a user mode service that installs new devices and communicates with other user mode processes, esp. the shell. Note that a device can be installed but not physically present; IE temporarily removed. See this page. Server and Workstation actually mean SMB Server and SMB Workstation. Mostly all they do is load their kernel-mode counterpart (srv.sys and mrxsmb.sys, respectively) and provide some helper support. Last time I checked, Samba, both smbd and smbclient were user-mode, although smbfs is a kernel FSD. The HID Input Service translates the special keys (like volume and internet) into actual events. Disable it and those keys won't work. I don't see why this should be in kernel mode.
I'm not saying that NT components have dependencies on Win32 components, I'm saying that the division of responsibilities between applications, Win32 modules, and the NT kernel are such that where a UNIX application would make a system call to the kernel and back out, an NT application may end up with the same operation implemented in Win32.
Win32 has to use kernel syscalls to do things, too. Win32 is an environment subsystem. It exists to provide an environment (and the services needed to implement it) that is different than the native environment (exported by ntdll). It is composed of two parts: 1. The client interface in the form of 4 main dlls: kernel32, gdi32, user32 and advapi. 2. The server, to arbitrate Win32 specific resources and implement proprietary communication; csrss.exe in winsrv.dll (win32k.sys post NT4). NT does not provide graphical output functions, so Win32 contains GDI. NT does not provide a window manager, so Win32 contains USER. Other than communicating with the Win32 server, the Win32 client libraries exist to repackage requests so they can be understood by the kernel. Let's say you open "C:\file.txt" using Win32's OpenFile from kernel32.dll. The kernel has no concept of drive letters, so Win32 maintains a directory in the Object Manager of symbolic links connecting those letters to actual devices. kernel32.dll will append it to the beginning of the requested path, producing "\DosDevices\C:\file.txt" and then make the syscall NtOpenFile in ntdll. Win32 is not involved at all past this point until it returns. The IO Manger asks the Object Manager to resolve the path. The ObjMgr figures out that \DosDevices\C: is a symbolic link to \Device\HarddiskVolume1, a device object and passes the rest of the path "\file.txt" to the IO Mgr with an open IRP. ws2_32.dll repackages socket open requests as a file operation to a protocol device such as \Device\Tcp. Win32 named objects just get "\BaseNamedObjects" appended in the front of them. A display driver talks to its port driver with a device object such as \Device\Video0. Anyways, Win32 may provide the interfaces your application uses, but most of those services are actually provided by the kernel, once translated from Win32. Note that no application is required to use Win32: you can certainly make syscalls directly. You could dispatch NtOpenFile for \Device\HarddiskVolume1\file.txt directly. You can even set your subsystem type in the PE header to 'native', which prevents any use of Win32.
That's a bit of a red herring. There are multiple implementations of the UNIX operating system, but with few exceptions they all (even most of the so-called microkernels) share the same basic design of a single process structure that switches between user and kernel mode using a common system-call interface, with
The installer should be distribution specific, not the packages!
Exactly.
The package should contain a detailed description of what is in the package, but no instructions on how to install it, per se. The installer's job is to figure out how to install based on the package's declared contents. The package includes a file marked as a shared library. The installer knows to put shared libraries in/usr/lib. Not from the package, but because that is system policy. The package has a binary marked as the GUI front end, so the installer knows to put a link to it on the user's desktop because that's where the user said new programs should go. The package states that a certain binary needs write access to certain files, so the installer makes sure it gets it (either by modifying permssions or changing the user it runs as), long as it doesn't violate the system security policy. Possibly with a warning to the user (do you trust this package? it has to run as root!) before installation. The package states that it contains a daemon, so the installer adds it to the appropriate config files. It needs to listen on a port, default 80, so the installer gives it a port, either by forwarding from 80 or telling it to use a different one, or asking the user (based on how involved the user wants to be). All of which can be configured in the distro's standard control panel type programs.
Thanks. I too want Linux to become the OS that revolves around the user; the OS that gives users all the choices and can make it all work. Denying its faults will get us nowhere. Discovery of a fault should be all about admitting, exploring and figuring out how to solve it. It isn't going to go away.
It would be great to have a software repository that anyone can add packages to, confident that they will run on anyone's computer (that has the standard installer). Packages can be endorsed (by digital signature) as stable, or safe (not malware), or with an open licence with source, and mirrored by sources you trust, such as distro maintainers. But without limiting users to a single source.
Native compilation is not the same as a binary installation.
And how, prey tell, is it different from the perspective of the user? In both cases, a package is downloaded and installed. The average user couldn't case less about technical details of how that happens; compilation or copy. As long as it is easy and it works.
Actually, if they didn't, they would have to enter pages of hex code, and yes, people really did so.
They used the obvious choice of copying the pre-compiled binaries from electronic distrobution media.
Good, you're one of the ten people on the planet who run Windows without admin rights.
It's not my fault if there are other people who aren't competent to run Windows.
I wonder how many people run Lindow--er Linspire as a normal user? Doesn't that make you root by default too? Is this Linux's fault, or the user's?
Pick your distro accordingly? What if I find out I've been using the wrong one, the one that doesn't support what I want it to? Should I *gasp* re-install with a new distro?
Yes.
Don't you think that's a bit of a big hammer to fix a problem that shouldn't exist in the first place, IE package incompatibility?
I never have to re-install Windows (the worst-operating-system-and-most-evil-ever-created bar-none) to install new software (or any other reason), why should I have to reinstall Linux, when the distro maintainers could just put their differences aside for a minute to create a standardized package format?
Only if the package is compatible with your distrobution. Only if the filesystem layout is supported. Then, yes, it can be that easy. These incompatibilities are one reason and are caused in part by each distrobution maintaining it's own set of packages.
However, there are very, very good reasons why the very latest version of any given package is not suitable for everyone.
There is a VERY big difference between 1.having a package that does not match the distro's policy but still being able to install it if you want to and 2.not being able to install a package because it is incompatible, even when it has nothing do do with distro policy of stability. There could be (and is) a warning about installing unstable packages: having incompatible packages so users can't install them at all is not necessary.
Meanwhile, distributions such as Red Hat offer cutting edge packages which contain all the latest features.
Red Hat does NOT have every package that Debian has. It has nothing to do with the distro policy and everything to do with incompatible formats.
The user is free to choose whatever update policy is appropriate for them.
As long as they pick one, and only one update policy for all packages. That's not what I call freedom.
Perhaps binary compatibility between formats would be nice, but there really isn't any compelling reason to strive for it. There is already compatibility in the form of "./configure && make && make install".
A package manager does much more than "./configure && make && make install". The latter is not a replacement. Without a package manager, you have to resolve dependencies manually and recursively. If it were this easy, package managers would be unnecessary.
If you never want to compile anything, just choose a distribution like Red Hat or Debian Unstable which offers the latest packages. If you don't mind waiting for new features, use something like Debian stable. It is all a matter of choice for the user. Things can be as easy or as hard as they wish.
Both Red Hat and Debian Unstable have packages that the other doesn't. I'm not even talking about the latest versions, but any version.
Yeah, things can be easy if you pick exactly one distrobution and never look at packages that aren't supported by it, and hard if you want to install whatever you want.
Are there a better way ? How can a software installer deal with an installed library which is of a version known to break its application ?
And the currently installed version is the newest, while an older version works OK? By design, this scenario is not handled. This is a problem. Libraries are supposed to maintain backwards compatibility, but don't always. I guess you either have to fix your app to not break (if the installer detects this, it must be fairly current), possibly because the breakage is your fault, install a local copy, have a newer version created that works and install that, or XP and.NET, use a side-by-side installation (SxS). I have to wonder how this could happen, though. If the installer catches it, then the problem was cought in testing in which case there should be time to fix it.
and those in windir\system32 are susceptible to being overwritten by careless installer.
No more susceptible than/usr/lib to an install script that wants to dump stuff there.
It just happen much less often in Linux.
This is true: it's one of the best things about Linux; the average package quality is much higher. Windows has some well-behaved programs (MS's own are usually good) but there are tons of bad third-party installers and apps.
you can build a package to be run on Debian Woody, or Sarge, or Red Hat or SuSE, or...
True. The problem is is that each package format is incompatible. Why is this necessary? If the author decides to make only 1 package that only works on Red Hat 9, and you are running Debian Woody, expect to be SOL unless you want to get the source out, fix dependencies by hand and get it to compile. This is the problem.
Just exactly the same you can build a package installable in Windows (well, maybe *not* in Windows, but in Windows 3.1 *or* Windows 9x *or* Windows NT/200x)
Windows 3.1 has been EOL for a long time. Windows Installer (.MSI) has been the standard package format for at least 4 years, and it works on 98,ME,2000,XP and 2003. It handles dependencies, file versions and can bootstrap itself (install itself without already having MSI).
There's a difference, still: you can easily manage to get *your* program to be officially bundled with your favourite(s) distribution to the very easiness of that distribution users. It is not *their* distribution, it is *your* distribution, so you won't have to wait on "theirs" to fix anything.
Really? I can submit a package to Debian and they are required to list it, distrubute it, mirror it, and support it? I don't think so. They pick what packages they want included in the distrobution; hence the name distrobution.
And even then, you can use the autotools to make a portable package so if you sorrily die just now, someone ten years from now can download the source code and use it with nothing more complicated than writing "./configure && make && make install" and then pressing ENTER.
Oh yeah? All from nothing more than a source tar plus make? All the dependencies will be magically resolved, the correct versions of all libraries will be magically installed, the right version of the compiler will be available, the file system layout will be what is expected, and nothing can go wrong? I had no idea autotools were magical.
Sheesh. If it were that easy, there would be no need for packages in the first place.
If you install from source, there is no installer package.
There are makefiles, make scripts, and config scripts. This is another format of installer package. You use a different program than a.deb or.msi to run it, it uses a different method of producing the end files, but what they do; their purpose is the same. Why do you think it's called "make install"?
For most apps, it's not an issue. You just compile it. Try installing Word 2003 on Win '98.
Woo; a 5 year old operating system isn't supported anymore. IIRC, Red Hat 6.0 was their state-of-the-art OS in 1998. Does Red Hat still supply supported.rpm packages for RH6.0? No: it's end of life. Has been for a while.
AVERAGE PEOPLE BOUGHT AND USED COMPUTERS BEFORE MICROSOFT OR WINDOWS. I was there; I know. There were no magic installers, but people still survived.
Guess what, there were still installers for average people to use back then! Average people did not compile from source. You'd think that Linux, a modern OS, wouldn't require average people to do something that hasn't been necessary since at least DOS to install their programs. Either the program ran directly off the disk, so no installation of any type was necessary, or it had a setup program. Possibly, the user would be required to simply copy some files or unpack a zip file. Programs did not use shared libraries that were not part of the operating system; all dependencies were included.
Then you've never used IE while surfing the web.
Yes I have, and no, things cannot magically install themselves on the system without sufficent privileges; I run IE without them.
Yes. That's why it's called freedom. Pick your distro accordingly. You're free to choose.
Free to choose your way or the highway. Sure; that's a choice. Where's the freedom to install packages from any distrobution, even if I'm not running it? Pick your distro accordingly? What if I find out I've been using the wrong one, the one that doesn't support what I want it to? Should I *gasp* re-install with a new distro? Yes, I could screw with the source files, but that defeats the purpose of a package manager: it turns the promise of installs easy as "apt-get install mypkg" into a lie.
The issue is about packages availaible on distro X, but not on distro Y and you are unfortunately using Y. Or your version of X is too old.
All that has been said is very nice, but there haven't been any good reasons why packages can't be compatible across all distros (or mainstream ones, at least).
It can't be both ways: installation on Linux can't be as easy as "apt-get install package" and still require users to compile from source, track dependencies and diagnose compilation problems, even sometimes. Truth is, it really isn't that easy, and few Linux supporters want to admit that.
You've got it backwards. Typically, there is an individual installer package for everything you install under Windows.
This is different than the library of.deb,.rpm or make/install scripts, that distros maintain, how?
With Linux, you have the option to do _./configure;make;make install_ from the source. It's really not that hard, and computer users should have some basic level of proficiency and be able to read a README file.
If it works. If you aren't missing dependencies. If your compiler is the right version. If you have the right version of all the libraries you need and their dependencies. That's the point of a package manager or installer; to handle all of that stuff so you don't have to. You were just saying to wait for a package from the distro maintainers. Now it's 'go fix it yourself' if you don't like it? That flippant attitude will be the first thing to turn people off of Linux.
If you need an OS that holds your hand, wipes your nose, and installs things behind your back, by all means stick with Windows.
When it comes making installing things as easy as advertised, it had better hold my hand. Isn't that the point of a package manager? That I can go "apt-get install mercury" and when it's done, it Just Works? When you say "installs things behind your back", what are you talking about? If you mean automatic installation of dependencies that I need, don't package managers on Linux do that too? I have never had anything installed that I didn't intend to install on any of my Windows or Linux machines.
Don't criticize Linux users for preferring more freedom.
Freedom to mess around with trying to compile the source and resolve dependencies manually when the maintaners for your distro can't be bothered to create a package and can't afford to support packages from other distos?
No, the proper solution (and has been since NT3.1) is to use the existing versioning API so that you never replace new files with old versions. See Version Information API since NT3.1, Setup API since NT4.0 and Win95 and Windows Installer since 2000 and addon for NT4 and Win98.
Most of the other stuff is to work around crappy applications that can't afford to follow guidelines. OLE components (OCXs for one) have always used GUIDs as strong identification, but the file version is a different issue.
If I write software, all I should release is the source code. Let the distributions package it for their architecture.
So then I'm at the mercy of the distro people? I have to wait for them to support the app (if they ever do); I have to wait for them for new versions, long after the creator has released it. I thought free software was supposed to be decentralized.
The people who are motivated to create the app (the author) should be the one releasing packages, not some third party. Think what it would be like if you couldn't install anything on Windows without Microsoft individually making a special installer package for it; you can still install but not without a major headache.
Huh? All Win32 binaries use a PE header which certainly has space for a version field. Microsoft has been using it since the first implementation of Win32 in NT3.1. See Version Information Overviews, VerInstallFile which only installs if your file is newer than the one you are trying to replace. The Setup API which has been around since NT4 and Win95 is another option; it also provides the.inf setup script environment. The Windows Installer is the current method. The problem is with setup programs that don't use any of these methods and simply unpack their files, blindly overwriting anything in the way.
having library spread all over your disk instead of having them in a central location, potential library overwriting (aka "DLL Hell") and no way to update library centrally
Make up your mind; either they are stored centrally and there wouldn't be extra copies or they are not stored centrally in which case DLL Hell is impossible. The standard way to install shared libraries is to put them into windir\system32, or possibly \program files\common files. Here's a list of system folders. Here are the guidelines for installation/uninstallation. If some app is storing a private copy of mfc42.dll or gdiplus.dll, they are violating those guidelines. I'm not suprised that it causes problems. Surely you aren't trying to blame Microsoft for third parties that ignore the established installation procedures?
The difference is that once you actually see a news broadcast
Since depictions of sex aren't on the news, this isn't a very good comparison.
you're bound to learn pretty quickly that you don't recover quickly and completely, etc.
Yes, expierence will give you direct information from reality. How does this apply to violence and not sex? If someone has unenjoyable sex, won't they remember that too?
"Aha! Most women don't want to get it in the ass!"
Really? You've done a proper statistical study on this, or can link to one? Otherwise, your statement has just as much backing (read: none) as the porno flicks. You can't make statments about what "Most women" want wihout one, or without asking every single woman. There isn't another way to find out most people's favorite color, either.
With porn, on the other hand, it's much different. The boundaries are vaguer.
How's this? Those involved either enjoy and wish to repeat it or they don't, and every shade of gray in-between. How is this different than any other activity, including violence?
Some of my friends still haven't got it, despite having had sex with dozens.
So your expierence is different than your friends. This invalidates their opinion because...? Did any of them force their partners to have anal sex: IE was it consentual? Did you actually interview each of their partners to ask them what they did in detail and how much they did or did not enjoy it? Where is the data to support your claim?
In order to tell the difference, you need to already have some idea of the truth. If your only source of information is consistent yet fictional, how can you know it's not true? In context of the thread, the issue is mainly about children. Children are usually not exposed to violence and sex first hand, so their only source of information on the subjects may come from fictional sources. How do you expect them to know it's fiction without being exposed to the truth? If everyone could always distinguish fact from fiction, then this entire issue would be moot. And I tend to agree with you; people shouldn't be sheilded from fiction. If they can't distinguish it, they are only hurting themselves. Sheilding them from it will hinder their ability to tell the difference. They most certainly should not be sheilded from the truth.
My post was in response to pilkul's statement that inacurate depictions of sex are harmful to children: if that's true then false depictions of anything would be harmful, including violence, while realistic depictions of anything wouldn't have to be. Note that I qualified with "can be damaging" not that they must be, that they "can be at least as dangerous", not that they are dangerous.
Just as getting an unrealistic picture of violence; that it is the solution to many problems, or that the heroes (who are designed to identify with the viewer) never die, and when hurt recover quickly and completely. These are falsities that can be at least as dangerous.
The common problem is unrealism. Depictions of either can be good (in moderation) when they are realistic, and both can be damaging when they are not.
Rampant violence on television doesn't justify pornography.
No, but it does hurt the credibility of those who would attack one and tolerate the other. The grandparent is asking a very good question of why gross violence is tolerated, but pictures of sex, even when it is realistic and informative (it isn't always, but failure to make any distinction is part of the problem) are attacked zealously. Why the uneven pressure? What's so much better about violence that it can be ignored? The grandparent makes a case that if one should get lesser pressure it should be the sex, not the violence.
Re:I've never quite understood...
on
Joel On Software
·
· Score: 3, Informative
What SuperKenall said is correct. However, some languages have more differences than others.
All the.NET languages MS ships are all about the same; the only difference is syntax..NET requires all compatible languages to adhere to the same capabilities so they can be 100% compatible with each other. Unfortunately, it also requires all the languages it supports to be dumbed down to the lowest common denominator. There is a very long list of things that had to be removed from ISO C++ to create Managed C++, because including them would make it incompatible with VB and C# (and.NET), such as multiple inheritance, templates (non-type params too), pointers, member pointers, etc.
Functionally, VB.NET, C#, J#, and Managed C++ all have exactly the same capibilities. They are all sequential, procedural, imperative, object-oriented languages that support single inheritance, interfaces, events, exceptions, type generics(they will in v2.0), reflection and share a common runtime library and work in a sandboxed VM. The ONLY differences between them are in syntax. So, it doesn't really matter which of these languages are used unless someone in the group doesn't know the syntax for a language in a source file they need to work on. The interfaces between them will be equivalent regardless of language.
Compare this to a functional language such as Common LISP or Scheme, or a declaritive rule-baed language like Prolog or Mercury. Mercury can compile to.NET (it normally compiles to C), but you can forget about a runtime system like Prolog being compatible with.NET..NET doesn't understand functions that don't have an implementation until you've decided the direction the argumets are flowing (a very big part of declaritive languages),.NET doesn't understand state tracking and backtracking or multiple modes based on detirminism,.NET doesn't understand multiple possible results for a single variable (a list is the closest you can get; it isn't the same because you have to do all the handling yourself which defeats the purpose). Haskell has to jump through hoops to get the needed multiple inheritance to work. OTOH, there are some interesting projects like F#, an OCaml like functional language. It has some serious issues to be compatible with.NET, though.
It's like Microsoft offers you several languages, but they are all the same. The illusion of choices without really having any. They should just be like Java and admit that there might as well be one language-- seriously, Java could have all the multi-language support of.NET if there were bytecode compilers for other languages..NET and Java are so alike in function anyways.
As for what languages should be used when, where and by whom: I don't know. I'm still trying to figure that out. I know that some are good and bad for certain things, but I also know that personal preference is important, too.
It's one thing to have great marksmanship, but when a grenade goes off a few feet away and he leaves with no hearing loss, no injuries of any kind, it's a bit silly. Also, he seems to be a bit too anti-authority for a Marine. Maybe that surfaced after he left the Corps?
The one dude who shot Ducky's assistant got the better of Gibbs, who also took a bullet to the arm for his trouble. Apparently you haven't watched the series that much, or are confusing it with CSI: Miami, or not paying attention.
That the bad guys sometimes win (temporarily; I'm sure he will be back to be revenged upon), even outsmart the good guys is very different than the bad guys manipulating them to do their bidding. Gibbs, however does it to them frequently. The bad guys always seem to be so stupid, except for a very small elite, whereas the good guys are never stupid.
I don't know much about the UCMJ, but I suspect they are a little more lax with warrants when other military personnel are involved.
I don't know how the UCMJ works exactly, but I hope it's more comprehensive than the gun-slinging wild west 'justice' that Gibbs & crew practice.
Other military personnel? I was under the impression that Gibbs wasn't in the military anymore. Furthermore, Gibbs prosecutes many non-military people whom the UCMJ doesn't apply to, but doesn't treat them any different. Note also that foreigners in US jurisdiction get all the legal due process rights of a US citizen. (in the real world)
There aren't any defendants that demand a lawyer, refuse to say anything and unconditionally force trial. (that I've seen; I may have missed the one case where that actually happens) In fact, I can't remember him ever actually taking anything to trial (there surely are military tribunals). I can't say that I've seen a single judge on the program, at all. Gibbs seems to answer to no one; just once I'd like to see him screw up royally on one of his idiotic gambles and be brought up on charges of recklessnes.
Eh, I must not have seen that one. It's rare, however.
Um, "NCIS" stands for "Naval Criminal Investigative Service". The UCMJ is a little more forgiving of things like that than is the Constitution.
On the show it stands for investigative service (a little), procsecution service, judgement service, and execution service. Navy involvement is nice but unnecessary.
Isn't the UCMJ, and in fact all of the government, subject to the Constitution?!
Slashdot Mirror
Once again, big hammer for (should be) small problem.For the web browser? Here.
The total number of syscalls on Linux 2.6.7, according to "arch/i386/kernel/entry.S", is 284: 1 less than XP. Woo!
This definition is over-reaching. There are user mode processes that do not depend on or are even aware of Win32. How about the Session Manager (init process)? It does not depend on Win32, does not run in kernel mode, and yet provides services from the "\SmApiPort" LPC port. What about other intrinisic subsystems like the Security Accounts Manager, the Local Security Authority, the Event Log, and user mode Plug & Play? There are many other services that use Win32 only for the service control interface, maintained by services.exe and the Win32 library interface. They don't care about the Win32 server's internal state, and so cannot be corrupted from it. These are services that have zero windows, the only Win32 specific message destination; they only link to advapi.dll and kernel32.dll, whose functions are handled by the kernel, not the Win32 server. In fact, according to Microsoft guidelines services are never supposed to create windows, exactly because it could be a security problem.
Since the Win32 server is a trusted component, taking control of it would mean control of the system.
Are you saying that corruption of Win32's state is unavoidable due to its design, or that Win32 adds too much attack area?
Looking through \BaseNamedObjects, there are exactly 0 shared memory "section" objects that are world-writable. There are 5 that only me personally can read and write to, 3 accessable to SYSTEM and Administrators, and several read-only to everyone. (excluding the sections made by Cygwin; insecure sections made by it to maintain state are a long-known problem) It's possible that there are some insecure sections that are being duplicated among processes (I doubt it as shared objects almost always have names, so they can be found easily: some process has to personally duplicate a handle for you otherwise), but I'm not about to check every unnamed section; perfmon tells me that there are 4171 section objects, more than any other type.
I get the feeling that sections are either used to advertise public information, exchange state between processes in the same security context (like the sections accessible only to me), as a private channel between two processes (I assume data there is checked like any other source), or to memory-map files. They aren't used to store common state information, far as I can tell. That's done in private memory in the service's server process.
In the kernel source, under include/linux/syscalls.h, I counted the number of asmlinkage functions, and got 268. From the filename and contents, I assume this defines the syscall entrypoints. To get XP's syscall count, I counted the number of Nt* functions exported from ntdll.dll, which is 285. If you have a better way to count them...
Windows has generic pipes, too. The console, pipes, sockets, anything you can use CreateFile on can all be accessed with the
Plug and Play is implemented in two parts: an executive service (in kernel mode) that communicates with drivers, enumerates busses and loads drivers for devices that are already installed, and a user mode service that installs new devices and communicates with other user mode processes, esp. the shell. Note that a device can be installed but not physically present; IE temporarily removed. See this page.
Server and Workstation actually mean SMB Server and SMB Workstation. Mostly all they do is load their kernel-mode counterpart (srv.sys and mrxsmb.sys, respectively) and provide some helper support. Last time I checked, Samba, both smbd and smbclient were user-mode, although smbfs is a kernel FSD.
The HID Input Service translates the special keys (like volume and internet) into actual events. Disable it and those keys won't work. I don't see why this should be in kernel mode.
Win32 has to use kernel syscalls to do things, too.
Win32 is an environment subsystem. It exists to provide an environment (and the services needed to implement it) that is different than the native environment (exported by ntdll). It is composed of two parts: 1. The client interface in the form of 4 main dlls: kernel32, gdi32, user32 and advapi. 2. The server, to arbitrate Win32 specific resources and implement proprietary communication; csrss.exe in winsrv.dll (win32k.sys post NT4). NT does not provide graphical output functions, so Win32 contains GDI. NT does not provide a window manager, so Win32 contains USER.
Other than communicating with the Win32 server, the Win32 client libraries exist to repackage requests so they can be understood by the kernel.
Let's say you open "C:\file.txt" using Win32's OpenFile from kernel32.dll. The kernel has no concept of drive letters, so Win32 maintains a directory in the Object Manager of symbolic links connecting those letters to actual devices. kernel32.dll will append it to the beginning of the requested path, producing "\DosDevices\C:\file.txt" and then make the syscall NtOpenFile in ntdll. Win32 is not involved at all past this point until it returns. The IO Manger asks the Object Manager to resolve the path. The ObjMgr figures out that \DosDevices\C: is a symbolic link to \Device\HarddiskVolume1, a device object and passes the rest of the path "\file.txt" to the IO Mgr with an open IRP.
ws2_32.dll repackages socket open requests as a file operation to a protocol device such as \Device\Tcp.
Win32 named objects just get "\BaseNamedObjects" appended in the front of them.
A display driver talks to its port driver with a device object such as \Device\Video0.
Anyways, Win32 may provide the interfaces your application uses, but most of those services are actually provided by the kernel, once translated from Win32.
Note that no application is required to use Win32: you can certainly make syscalls directly. You could dispatch NtOpenFile for \Device\HarddiskVolume1\file.txt directly. You can even set your subsystem type in the PE header to 'native', which prevents any use of Win32.
The package should contain a detailed description of what is in the package, but no instructions on how to install it, per se. The installer's job is to figure out how to install based on the package's declared contents.
The package includes a file marked as a shared library. The installer knows to put shared libraries in
The package has a binary marked as the GUI front end, so the installer knows to put a link to it on the user's desktop because that's where the user said new programs should go.
The package states that a certain binary needs write access to certain files, so the installer makes sure it gets it (either by modifying permssions or changing the user it runs as), long as it doesn't violate the system security policy. Possibly with a warning to the user (do you trust this package? it has to run as root!) before installation.
The package states that it contains a daemon, so the installer adds it to the appropriate config files.
It needs to listen on a port, default 80, so the installer gives it a port, either by forwarding from 80 or telling it to use a different one, or asking the user (based on how involved the user wants to be).
All of which can be configured in the distro's standard control panel type programs.
Thanks.
I too want Linux to become the OS that revolves around the user; the OS that gives users all the choices and can make it all work. Denying its faults will get us nowhere. Discovery of a fault should be all about admitting, exploring and figuring out how to solve it. It isn't going to go away.
It would be great to have a software repository that anyone can add packages to, confident that they will run on anyone's computer (that has the standard installer). Packages can be endorsed (by digital signature) as stable, or safe (not malware), or with an open licence with source, and mirrored by sources you trust, such as distro maintainers. But without limiting users to a single source.
I wonder how many people run Lindow--er Linspire as a normal user? Doesn't that make you root by default too? Is this Linux's fault, or the user's?Don't you think that's a bit of a big hammer to fix a problem that shouldn't exist in the first place, IE package incompatibility?
I never have to re-install Windows (the worst-operating-system-and-most-evil-ever-created bar-none) to install new software (or any other reason), why should I have to reinstall Linux, when the distro maintainers could just put their differences aside for a minute to create a standardized package format?
Only if the package is compatible with your distrobution. Only if the filesystem layout is supported. Then, yes, it can be that easy. These incompatibilities are one reason and are caused in part by each distrobution maintaining it's own set of packages.
Yeah, things can be easy if you pick exactly one distrobution and never look at packages that aren't supported by it, and hard if you want to install whatever you want.
I have to wonder how this could happen, though. If the installer catches it, then the problem was cought in testing in which case there should be time to fix it.No more susceptible than
Windows has some well-behaved programs (MS's own are usually good) but there are tons of bad third-party installers and apps.
Sheesh. If it were that easy, there would be no need for packages in the first place.
You use a different program than a
Where's the freedom to install packages from any distrobution, even if I'm not running it?
Pick your distro accordingly? What if I find out I've been using the wrong one, the one that doesn't support what I want it to? Should I *gasp* re-install with a new distro? Yes, I could screw with the source files, but that defeats the purpose of a package manager: it turns the promise of installs easy as "apt-get install mypkg" into a lie.
The issue is about packages availaible on distro X, but not on distro Y and you are unfortunately using Y. Or your version of X is too old.
All that has been said is very nice, but there haven't been any good reasons why packages can't be compatible across all distros (or mainstream ones, at least).
It can't be both ways: installation on Linux can't be as easy as "apt-get install package" and still require users to compile from source, track dependencies and diagnose compilation problems, even sometimes. Truth is, it really isn't that easy, and few Linux supporters want to admit that.
You were just saying to wait for a package from the distro maintainers. Now it's 'go fix it yourself' if you don't like it? That flippant attitude will be the first thing to turn people off of Linux.When it comes making installing things as easy as advertised, it had better hold my hand. Isn't that the point of a package manager? That I can go "apt-get install mercury" and when it's done, it Just Works?
When you say "installs things behind your back", what are you talking about? If you mean automatic installation of dependencies that I need, don't package managers on Linux do that too? I have never had anything installed that I didn't intend to install on any of my Windows or Linux machines.Freedom to mess around with trying to compile the source and resolve dependencies manually when the maintaners for your distro can't be bothered to create a package and can't afford to support packages from other distos?
No, the proper solution (and has been since NT3.1) is to use the existing versioning API so that you never replace new files with old versions. See Version Information API since NT3.1, Setup API since NT4.0 and Win95 and Windows Installer since 2000 and addon for NT4 and Win98.
Most of the other stuff is to work around crappy applications that can't afford to follow guidelines.
OLE components (OCXs for one) have always used GUIDs as strong identification, but the file version is a different issue.
The people who are motivated to create the app (the author) should be the one releasing packages, not some third party. Think what it would be like if you couldn't install anything on Windows without Microsoft individually making a special installer package for it; you can still install but not without a major headache.
The problem is with setup programs that don't use any of these methods and simply unpack their files, blindly overwriting anything in the way.Make up your mind; either they are stored centrally and there wouldn't be extra copies or they are not stored centrally in which case DLL Hell is impossible.
The standard way to install shared libraries is to put them into windir\system32, or possibly \program files\common files. Here's a list of system folders. Here are the guidelines for installation/uninstallation.
If some app is storing a private copy of mfc42.dll or gdiplus.dll, they are violating those guidelines. I'm not suprised that it causes problems. Surely you aren't trying to blame Microsoft for third parties that ignore the established installation procedures?
There isn't another way to find out most people's favorite color, either.How's this? Those involved either enjoy and wish to repeat it or they don't, and every shade of gray in-between. How is this different than any other activity, including violence?So your expierence is different than your friends. This invalidates their opinion because...?
Did any of them force their partners to have anal sex: IE was it consentual?
Did you actually interview each of their partners to ask them what they did in detail and how much they did or did not enjoy it?
Where is the data to support your claim?
I see your point.
In order to tell the difference, you need to already have some idea of the truth. If your only source of information is consistent yet fictional, how can you know it's not true? In context of the thread, the issue is mainly about children. Children are usually not exposed to violence and sex first hand, so their only source of information on the subjects may come from fictional sources. How do you expect them to know it's fiction without being exposed to the truth? If everyone could always distinguish fact from fiction, then this entire issue would be moot. And I tend to agree with you; people shouldn't be sheilded from fiction. If they can't distinguish it, they are only hurting themselves. Sheilding them from it will hinder their ability to tell the difference. They most certainly should not be sheilded from the truth.
My post was in response to pilkul's statement that inacurate depictions of sex are harmful to children: if that's true then false depictions of anything would be harmful, including violence, while realistic depictions of anything wouldn't have to be. Note that I qualified with "can be damaging" not that they must be, that they "can be at least as dangerous", not that they are dangerous.
Just as getting an unrealistic picture of violence; that it is the solution to many problems, or that the heroes (who are designed to identify with the viewer) never die, and when hurt recover quickly and completely. These are falsities that can be at least as dangerous.
The common problem is unrealism. Depictions of either can be good (in moderation) when they are realistic, and both can be damaging when they are not.
What's so much better about violence that it can be ignored? The grandparent makes a case that if one should get lesser pressure it should be the sex, not the violence.
What SuperKenall said is correct. However, some languages have more differences than others.
.NET languages MS ships are all about the same; the only difference is syntax. .NET requires all compatible languages to adhere to the same capabilities so they can be 100% compatible with each other. Unfortunately, it also requires all the languages it supports to be dumbed down to the lowest common denominator. There is a very long list of things that had to be removed from ISO C++ to create Managed C++, because including them would make it incompatible with VB and C# (and .NET), such as multiple inheritance, templates (non-type params too), pointers, member pointers, etc.
.NET (it normally compiles to C), but you can forget about a runtime system like Prolog being compatible with .NET. .NET doesn't understand functions that don't have an implementation until you've decided the direction the argumets are flowing (a very big part of declaritive languages), .NET doesn't understand state tracking and backtracking or multiple modes based on detirminism, .NET doesn't understand multiple possible results for a single variable (a list is the closest you can get; it isn't the same because you have to do all the handling yourself which defeats the purpose). .NET, though.
.NET if there were bytecode compilers for other languages. .NET and Java are so alike in function anyways.
All the
Functionally, VB.NET, C#, J#, and Managed C++ all have exactly the same capibilities. They are all sequential, procedural, imperative, object-oriented languages that support single inheritance, interfaces, events, exceptions, type generics(they will in v2.0), reflection and share a common runtime library and work in a sandboxed VM. The ONLY differences between them are in syntax. So, it doesn't really matter which of these languages are used unless someone in the group doesn't know the syntax for a language in a source file they need to work on. The interfaces between them will be equivalent regardless of language.
Compare this to a functional language such as Common LISP or Scheme, or a declaritive rule-baed language like Prolog or Mercury. Mercury can compile to
Haskell has to jump through hoops to get the needed multiple inheritance to work.
OTOH, there are some interesting projects like F#, an OCaml like functional language. It has some serious issues to be compatible with
It's like Microsoft offers you several languages, but they are all the same. The illusion of choices without really having any. They should just be like Java and admit that there might as well be one language-- seriously, Java could have all the multi-language support of
As for what languages should be used when, where and by whom: I don't know. I'm still trying to figure that out. I know that some are good and bad for certain things, but I also know that personal preference is important, too.
</rant>
Other military personnel? I was under the impression that Gibbs wasn't in the military anymore.
Furthermore, Gibbs prosecutes many non-military people whom the UCMJ doesn't apply to, but doesn't treat them any different. Note also that foreigners in US jurisdiction get all the legal due process rights of a US citizen. (in the real world)
There aren't any defendants that demand a lawyer, refuse to say anything and unconditionally force trial. (that I've seen; I may have missed the one case where that actually happens) In fact, I can't remember him ever actually taking anything to trial (there surely are military tribunals). I can't say that I've seen a single judge on the program, at all. Gibbs seems to answer to no one; just once I'd like to see him screw up royally on one of his idiotic gambles and be brought up on charges of recklessnes.
Isn't the UCMJ, and in fact all of the government, subject to the Constitution?!