Why are you maximizing your browser? To fit more text on the screen? Is that a bad idea?
I, on my hand, would like to question if you really need your buddy list constantly visible, or, for that matter, if you really need to constantly reserve space for a potential PDF document. Wouldn't it be better to use that space for the browser while you're not actively reading the PDF?
Funny as you may have been, I for one am looking forward to the BSOD patch. It would be quite helpful to actually be able to see a panic message even though an X server is running. Not that I'm encountering more than one every two years or so, but nonetheless.
First... C drive? I'm guessing you grew up on Windows. On Ubuntu, that's probably/dev/sda, but you never know... Actually, he's not that far off. It may have been Microsoft that came up with the specific "C:" mapping, but that implementation is very deeply rooted in how disk drives are accessed through the BIOS interface. Thus, as he was talking about the BIOS, the term "C drive" isn't at all that bad. Of course, the BIOS is one of those things like Windows that ought to go the way of the dodo.
You can't tell him why he's wrong, but by the gods, you're going to try anyway. Of course I cannot tell why he is wrong -- I have no idea how his thought processes work. I merely pointed out in what things he was factually wrong, in the hope that he himself might see and correct the underlying errors of his thinking. Is that wrong?
Wait, the iPhone OS X can run on a several devices, with as little as a 133 MHz processor with 16MB of RAM? I'm no Apple fanboy, but I don't really think that your points are valid anyway. Apple has no embedded device with a 133 MHz processor and 16 MB of RAM, so why should they even try to make the iPhone OS X run on such a device? In fact, since there has been no attempt to run it on such a device, how can you even sound so sure that it cannot be done?
Wait, Apple didn't have to customize OS X to run on the iPhone, it was perfect the way it was? Of course they had to -- it is called "porting" the operating system to a new hardware platform, and it is a different process from writing a new system from scratch. You may have heard already, but there are several so called "Linux distros", many being ports of an operating system to different platforms, without necessarily making it a completely different system.
Wait, it's easier for people to develop and distrubte applications for the iPhone, even though the ability isn't avaiable yet? While the iPhone SDK hasn't been publicly released yet, it was pretty clear from Apple's Keynote demonstration of it that it still uses all the standard OS X libraries and interfaces (with, of course, the addition of the libraries for the new UI elements).
Of course, your being wrong does not necessarily make Gartner right, but I don't know enough about such things as Embedded XP to make any claims in either direction.
It's 6 bit per color in a rgb scheme, making it 18 bit or 262,144 total. And while it is true that that is indeed 98% fewer discrete colors than the normal 16,777,216 discrete colors that can be displayed in a 24-bit colorspace, I still think that it is very misleading to say that. There is nothing in that which says that the actual color space has shrinked (meaning that the screen should still be able to display the same exact same range of colors), only that fewer colors from it can be picked.
Of course, that doesn't mean that it wouldn't matter, and I do think that people should be complaining, indeed, but saying that it shows 98% fewer colors makes the problem sound a lot more severe than it might actually be.
Of course it didn't help that Kerb was designed for the Unix UID/GID model Would you mind expanding on that a bit? As far as I'm aware, a UID or GID is part of the Kerberos protocol in any way, shape or form. A Kerberos principal is a name and a domain, which I think should map pretty fine onto Windows' model.
The extended stuff was Windows domain membership and so on. If MS didn't require that in the client implementation it would have been useless as Windows logon mechanism, or at least it wouldn't be feature-equivalent to the old lanman one. You may want to read this, by Microsoft's Peter Brundrett. A quote: "Using NTLM authentication, the user's SID and the group's SIDs are received directly from the server's DC, and any trusted domains, using the Netlogon secure channel. Using the Kerberos protocol, user and group SIDs are transmitted in the authorization data of the Kerberos session ticket."
Obviously, then, it should have been possible to fetch that data from the DC (probably using LDAP) with AD as well. Any way I look at it, it seems they did it to prevent non-Microsoft KDCs to work with Microsoft clients. Especially seeing how the authorization data in the ticket is something as simple as the Windows SIDs for the user.
I agree that the Kerberos issue is not as bad as many seem to think it is, but that does not mean that it isn't bad. They may not have violated the letter of the standard in implementing AD, but I would certainly argue that they violated the spirit of the standard, and did so for arguable malevolent reasons. What they did wasn't just to put optional, vendor-specific data in the vendor specific fields, but they also require that that vendor-specific data be present in their client implementation. Sure enough, it is possible to create manual mappings on the clients to accept tickets from non-Windows Kerberos servers, but to my knowledge, that is a manual process that cannot easily be duplicated over several clients or put into the directory as such.
Thus, the consequence is essentially that Windows clients need to use a Windows server for getting tickets, which, I would argue, was precisely their intention in doing so. That way, they can lock out non-Microsoft products from the servers, where they don't have a strong market lock-in, and still claim interoperability since non-Microsoft clients can still use Windows servers for authentication. I don't think that's just a coincidence resulting from the best possible technical implementation of their authentication protocol, especially seeing how the vendor-specific data could just as well be put in the LDAP directory instead (at least as I've understood it, it's just information on what groups the principal is a member of).
Microsoft may well not have violated the standard, but saying that what they did is perfectly alright, is a bit like saying that it's OK to murder people on the moon, just because there's no law enforcement there. And, especially seeing how it's Microsoft, I would be surprised if it were not part of an orchestrated effort, rather than just a small technical glitch.
I don't know any details about the mentioned problems with Java and CSS, but I would not at all be surprised to find the same thing there, as well.
Now I wouldn't mind a system that has both worlds: single-click installable packages (deb/rpm) that also prompt the user to add the third-party repository on install, so that they would then appear in Synaptic/etc. from then on. In that case, you may want to look at Autopackage. It even lets you install programs in your home directory, so you don't need root access to the system. It is also worth noting that installing Autopackages really is single-click, unlike e.g. Windows' setup.exe files, where you need to click "Next" five times, often seemingly unnecessarily.
Admittedly, it doesn't yet have a UI for updating packages automatically from their sources, but the infrastructure for it seems to be in place (and is used to fetch dependencies), so I'd be surprised if that functionality isn't added soon enough.
I may have to concede that it seems like an interesting idea with using the Violin thing for swap, however with two counterpoints:
To use the Violin as a swap device, it seems to me that it would work perfectly as just a normal ramdisk, without any special logic to synchronize to non-volatile storage, so it does not seem like much of an argument in favor of Ramback, but rather like one in favor of the Violin.
I would question the need for 512 GB of swap, seeing how I almost never use any swap with just 1 GB of RAM. I'm sure there are people somewhere who may need that much swap, though.
I am still not convinced on the whole Ramback vs. buffer cache point, though. Ignoring your point about the UPS mode (seeing how it only seems to be needed when using Ramback anyway), and addressing the population point instead; Surely, running "cat/dev/backing >/dev/null" should populate the buffer cache as fast and well as populating a Ramback (and it will still be able to serve sporadic reads from not-yet-populated pages), or am I wrong? As long as one really does have lots and lots of RAM, am I not right in saying that the buffer caches won't ever leave RAM anyway?
As for what you say about the buffer cache not knowing how to flush dirty cache to disk, I'm not sure what you may be referring to. For sure, the buffer cache already flushes dirty pages after some time has passed (as controlled by the vm.dirty_writeback_centisecs sysctl), but I cannot imagine you being unaware of this, so you must be referring to some other effect of which I am unaware.
Yeah, imagine, then, to be able to use such a fast disk as your swap device! That'll make your system swiftz0rs. Or, hey, wait a minute...
In all honesty, though, I don't really get the point of this. Isn't the buffer cache already supposed to be doing kind of the same thing, only with a less strict mapping?
This is in contrast to Linux, where updating to a new kernel (belonging to the same "stable" kernel branch, or even applying security patches) can make programs break until you recompile them. Huh? Not that I wouldn't like to argue that FreeBSD has many advantages over Linux, but that has to be one of those disadvantages of Linux that I haven't noticed so far. I would like to ask you to quote at least one example of Linux ABI breaking, because I sure haven't noticed any (at least not over the last couple of years). Of course, I shan't swear that that is thanks to the kernel as much as it is thanks to glibc, but I don't think that would change my point very much, since not many programs should be talking directly with the kernel anyway.
Also, in terms of virtualization - a single mainframe on z/Linux can host many virtual linux servers I've never really understood that idea, though, so hopefully you might explain it to me. Why would one want to run several instances of the same operating system on one machine? Why not just run one instance of Linux and let it handle it all, instead of dividing it up? It just seems you'd get more overhead that way, to me.
Really? If that is truly so, then I'd argue that that is what is the actual security flaw, and not the non-randomness of the IDs. For sure, you won't be able to carry out any of the IP attacks that way, since fragment IDs are local to the sending host. To be honest, I didn't understand how the DNS vulnerability worked to begin with (I didn't see it being explained anywhere), so I can't make any statements about it, though.
I'm no security expert and I don't know anything about the attack vectors that he claims, so maybe I shouldn't say too much, but I do know this: TFA mentions that the PRNG is used for such fields as DNS transaction IDs and IP header fragment IDs, and these fields were never even meant to be random from the beginning. Verily so, TFA even says that {Free,Net}BSD don't even use the PRNG by default, but uses sequential numbers unless a certain sysctl is tweaked.
Thus, it is my guess that even if the attack vectors are deemed serious enough, the OpenBSD team has decided that it doesn't matter, since these protocols were never designed for security anyway, and that one should use DNSSEC and/or IPSEC (or TLS) if one actually wants to be secure (it does raise the question as to why they decided to use a PRNG for those fields from the beginning, though). My second guess is that they don't even consider the attack vectors serious, though, since they probably require a cracked router to be effective anyway.
Indeed, if they do require a cracked router, then I don't see the issue to begin with. One of the attacks was that the attacker could inject data into a TCP stream and such things, and if he has a router cracked, then I'm pretty sure he could forge all the data he wants anyway, without using any particular software attack at all, and likewise with DNS data.
I may well agree that the effects of PolicyKit are a good thing, but I have to say that I am not immediately convinced of its D-Bus implementation. D-Bus may be fun and all, but I'm getting the feeling that Linux distributions are increasingly turning into D-Bus distributions. IIRC, Red Hat has even announced a project for a D-Bus based init replacement. I liked D-Bus when it was all about the desktop, and getting the occasional system level abstraction like HAL, BlueZ or possibly NetworkManager to speak to desktop programs, but now I feel it is beginning to replace core POSIX policies.
Not that a D-Bus operating system couldn't possibly be good, but all I really want, quite honestly, is a good Unix system. More D-Bus at the system level is, for me, rather an argument to switch my laptop over to Debian instead, and then if Debian becomes GNU/DBus as well, I guess I'll switch to FreeBSD instead.
In all seriousness, the article speaks of ship mounted guns, so I don't really think they are made to kill individuals. I would think that no amount of energy can ever be enough when it comes to sinking warships.
It makes me wonder, though -- they say 32 MJ per shot, but how much energy is in a normal-sized conventional weapon? They also say Mach 8, but how fast are normal rounds fired?
I'm not sure exactly how this works, so I can't go into all too nitty-gritty details, but basically, it's like this.
x86 CPUs (and probably amd64 as well) allow the kernel to choose between two page sizes: The usual 4 kB ones and a much larger size (I think it's 1 MB or so). The performance issue is that if the kernel can keep the physical RAM pages that back a large contiguous virtual mapping contiguous in physical RAM, it can use one of the jumbo pages instead of potentially hundreds of 4 kB pages. Doing so saves both page table space by itself, but more importantly, it allows the CPU to cache the page table in much fewer TLB rows. If a 1 MB mapping can be cached in one TLB row, the CPU won't need to swap TLB entries back and forth from the physical page table. Even if the page table may be cached in the normal CPU memory cache, it would still result in far better bus performance.
HDCP (be it over HDMI, DVI or DisplayPort) is only required for playing back DRM-infested media at full resolution on DRM-infested OSes like Vista. Is that really true? As far as I know, HDCP is at the very least a required part of the HDMI specification, so devices need to implement it in order to be HDMI-certified. What I don't know is whether or not they use it by default, or even whether it's possible to turn it off.
Since all devices need to implement HDCP anyway, I wouldn't be at all surprised if the use of it is mandatory as well. Even if it isn't mandatory, it wouldn't surprise me if most/many devices simply won't work if its peer on the link refuses to use HDCP.
I've been wondering about this for a long time now and have been hesitant to use HDMI for any purpose not knowing the answer (not only just because it is DRM, but also because I read previously on/. that HDCP is what is causing the vast majority of problems when using HDMI). I'd really appreciate it if someone could tell me (or, of course, link to the answer).
If you don't believe me, find a geek who hasn't heard of 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0. I have that stupid thing memorized. Thank you for your confession. Since, by your own account, there are synapse patterns in your brain that constitute a derived work of AACSLA protected material, you are to report to your nearest copyright enforcement facility to have your brain lobotomized in order to remove the infringing material.
... I guess. So then, I'd just need Flash, my absolute favorite proprietary piece of software. And I need Linux or OS X; not FreeBSD, Plan9 or bOS.
I don't know -- I probably won't be using the service anyway, and I'm not a British citizen anyway, so I don't really feel that I have the right to complain, but it still bothers me when public services don't actually make their service free for real. I know I'd be bothered for real if my own government did something like it, at least.
Not really a replacement
on
Hacking VIM
·
· Score: 1
It is interesting that the summary tells us that vim has replaced vi completely, when the good old vi is still the default on the BSDs, though. It must be because BSD is reportedly dead.:)
I think you've probably misunderstood something. The LPGL doesn't mean that Apple would be free to hide its presence or source code or anything of the kind. It just means that it is allowed to link Wine into proprietary programs. They would still need to both inform the world that they have included Wine, and to provide its source code and a way to rebuild both Wine itself and any programs that would be linked statically against Wine. This is in contrast with the GPL only in the way that proprietary programs are not even allowed to link against GPL'ed code.
Slashdot Mirror
I, on my hand, would like to question if you really need your buddy list constantly visible, or, for that matter, if you really need to constantly reserve space for a potential PDF document. Wouldn't it be better to use that space for the browser while you're not actively reading the PDF?
Funny as you may have been, I for one am looking forward to the BSOD patch. It would be quite helpful to actually be able to see a panic message even though an X server is running. Not that I'm encountering more than one every two years or so, but nonetheless.
Of course, that doesn't mean that it wouldn't matter, and I do think that people should be complaining, indeed, but saying that it shows 98% fewer colors makes the problem sound a lot more severe than it might actually be.
Obviously, then, it should have been possible to fetch that data from the DC (probably using LDAP) with AD as well. Any way I look at it, it seems they did it to prevent non-Microsoft KDCs to work with Microsoft clients. Especially seeing how the authorization data in the ticket is something as simple as the Windows SIDs for the user.
Thus, the consequence is essentially that Windows clients need to use a Windows server for getting tickets, which, I would argue, was precisely their intention in doing so. That way, they can lock out non-Microsoft products from the servers, where they don't have a strong market lock-in, and still claim interoperability since non-Microsoft clients can still use Windows servers for authentication. I don't think that's just a coincidence resulting from the best possible technical implementation of their authentication protocol, especially seeing how the vendor-specific data could just as well be put in the LDAP directory instead (at least as I've understood it, it's just information on what groups the principal is a member of).
Microsoft may well not have violated the standard, but saying that what they did is perfectly alright, is a bit like saying that it's OK to murder people on the moon, just because there's no law enforcement there. And, especially seeing how it's Microsoft, I would be surprised if it were not part of an orchestrated effort, rather than just a small technical glitch.
I don't know any details about the mentioned problems with Java and CSS, but I would not at all be surprised to find the same thing there, as well.
Admittedly, it doesn't yet have a UI for updating packages automatically from their sources, but the infrastructure for it seems to be in place (and is used to fetch dependencies), so I'd be surprised if that functionality isn't added soon enough.
I may have to concede that it seems like an interesting idea with using the Violin thing for swap, however with two counterpoints:
I am still not convinced on the whole Ramback vs. buffer cache point, though. Ignoring your point about the UPS mode (seeing how it only seems to be needed when using Ramback anyway), and addressing the population point instead; Surely, running "cat /dev/backing >/dev/null" should populate the buffer cache as fast and well as populating a Ramback (and it will still be able to serve sporadic reads from not-yet-populated pages), or am I wrong? As long as one really does have lots and lots of RAM, am I not right in saying that the buffer caches won't ever leave RAM anyway?
As for what you say about the buffer cache not knowing how to flush dirty cache to disk, I'm not sure what you may be referring to. For sure, the buffer cache already flushes dirty pages after some time has passed (as controlled by the vm.dirty_writeback_centisecs sysctl), but I cannot imagine you being unaware of this, so you must be referring to some other effect of which I am unaware.
In all honesty, though, I don't really get the point of this. Isn't the buffer cache already supposed to be doing kind of the same thing, only with a less strict mapping?
Really? If that is truly so, then I'd argue that that is what is the actual security flaw, and not the non-randomness of the IDs. For sure, you won't be able to carry out any of the IP attacks that way, since fragment IDs are local to the sending host. To be honest, I didn't understand how the DNS vulnerability worked to begin with (I didn't see it being explained anywhere), so I can't make any statements about it, though.
Yeah, what if? It's not as if any of these attack vectors would let you compromise a system, at least not by themselves.
Thus, it is my guess that even if the attack vectors are deemed serious enough, the OpenBSD team has decided that it doesn't matter, since these protocols were never designed for security anyway, and that one should use DNSSEC and/or IPSEC (or TLS) if one actually wants to be secure (it does raise the question as to why they decided to use a PRNG for those fields from the beginning, though). My second guess is that they don't even consider the attack vectors serious, though, since they probably require a cracked router to be effective anyway.
Indeed, if they do require a cracked router, then I don't see the issue to begin with. One of the attacks was that the attacker could inject data into a TCP stream and such things, and if he has a router cracked, then I'm pretty sure he could forge all the data he wants anyway, without using any particular software attack at all, and likewise with DNS data.
Not that a D-Bus operating system couldn't possibly be good, but all I really want, quite honestly, is a good Unix system. More D-Bus at the system level is, for me, rather an argument to switch my laptop over to Debian instead, and then if Debian becomes GNU/DBus as well, I guess I'll switch to FreeBSD instead.
It makes me wonder, though -- they say 32 MJ per shot, but how much energy is in a normal-sized conventional weapon? They also say Mach 8, but how fast are normal rounds fired?
Did you deliberately screw up that correction of a correction of a correction? You did, didn't you?
x86 CPUs (and probably amd64 as well) allow the kernel to choose between two page sizes: The usual 4 kB ones and a much larger size (I think it's 1 MB or so). The performance issue is that if the kernel can keep the physical RAM pages that back a large contiguous virtual mapping contiguous in physical RAM, it can use one of the jumbo pages instead of potentially hundreds of 4 kB pages. Doing so saves both page table space by itself, but more importantly, it allows the CPU to cache the page table in much fewer TLB rows. If a 1 MB mapping can be cached in one TLB row, the CPU won't need to swap TLB entries back and forth from the physical page table. Even if the page table may be cached in the normal CPU memory cache, it would still result in far better bus performance.
Since all devices need to implement HDCP anyway, I wouldn't be at all surprised if the use of it is mandatory as well. Even if it isn't mandatory, it wouldn't surprise me if most/many devices simply won't work if its peer on the link refuses to use HDCP.
I've been wondering about this for a long time now and have been hesitant to use HDMI for any purpose not knowing the answer (not only just because it is DRM, but also because I read previously on /. that HDCP is what is causing the vast majority of problems when using HDMI). I'd really appreciate it if someone could tell me (or, of course, link to the answer).
I don't know -- I probably won't be using the service anyway, and I'm not a British citizen anyway, so I don't really feel that I have the right to complain, but it still bothers me when public services don't actually make their service free for real. I know I'd be bothered for real if my own government did something like it, at least.
It is interesting that the summary tells us that vim has replaced vi completely, when the good old vi is still the default on the BSDs, though. It must be because BSD is reportedly dead. :)
I think you've probably misunderstood something. The LPGL doesn't mean that Apple would be free to hide its presence or source code or anything of the kind. It just means that it is allowed to link Wine into proprietary programs. They would still need to both inform the world that they have included Wine, and to provide its source code and a way to rebuild both Wine itself and any programs that would be linked statically against Wine. This is in contrast with the GPL only in the way that proprietary programs are not even allowed to link against GPL'ed code.