As soon as you use someone else's hardware, you're necessarily risking your SSH key. You don't know whether there's a hardware keylogger. You don't know whether there's nastyware deliberately or accidentally installed. But security is never absolute anyhow.
The Rush CD IS louder. Because the compression makes its average amplitude greater.
And really, I think it's done because when you're listening to the radio, you often aren't giving it your full attention. You don't want something with loads of dynamic range for background music.
2. They aren't given equal treatment because their prosthetics aren't chosen from necessity.
Of course, "necessity" isn't an absolute-- perception of what is necessary does change. Can you remember when microcomputers weren't necessary? A while ago, huh?
Remember when lefties were forced to use their right hands? Me neither.
Apple may have more control of hardware than Microsoft, but I don't believe that's relevent to the choice of software APIs. This isn't about the device driver model, or anything.
If anything, Apple's control is less firm than Microsoft's, because developers don't have to support them, but supporting Windows is pretty well mandatory for many kinds of applications.
Let me vote for standardization. The most convenient interface should expose the recommended set of operations. If there's a demand for the ability to do things the wrong way, 1. It's an opportunity to improve the design of the recommended API so it can accomodate more developers. 2. You can expose a second API for "Bad" operations.
Microsoft seems to be voting for resolution-independence with Longhorn.
Browsers do override CSS pixel settings. At the user's request, Mozilla will scale the text in any web page, and Opera will scale the bitmaps as well as the text.
Of course, scaling web page images would look nicer with vectors...
I dunno. I didn't compare Windows developers to Linux developers.
The Windows GUI hands a lot of control to the developer. They can't be trusted with that power. They do stupid things like writing GUIs with system privileges.
There are big differences between the output of a paid Windows development team and a volunteer open-source developer, but they're not a different species. They may even be the same person at work and at play.
In any case, I'm saying a well-designed API is hard to use wrong and easy to use right.
In other words, it's up to the app developer to base their UI on the dynamic System Properties rather than on fixed values
You say that like it's a good thing.
Time and time again, Windows developers have shown they can't be trusted to future-proof their apps.
Anyhow, using bitmaps for UI is an optimization that has overstayed its welcome. Vectors are far cooler.
The only reason bitmaps were better in the old days is that screen resolution was universally crappy. Back in the day, we had 320x200, and we were grateful. (Apparently, there was even a CGA 160x100 high-colour mode.) We had to target every pixel, because a difference of one pixel was huge.
The monitor I'm using right now supports 1600x1200, but I'm running at 1280x960 because I don't want everything to be tiny. This is a travesty. Resolution shouldn't affect size, just detail. With OS X, that's how it works.
There's always another way; I produce PDF files using PDFLib. They most definitely look the same every time.
Re:Data, even metadata, belongs in files, not fs
on
State Of The Filesystem
·
· Score: 2, Informative
As the poster noted, it's possible to run your filters in user space, not kernel space, so buffer overflows and segfaults should be sources of irritation, not sources of vulnerabilities.
None of the reasons you give (speed, security, error correction) are reaons to change systems. Error correction is handled by media-- that is, hard disks-- these days. (See that article "You Don't Know Jack about Hard Disks" from a day or so ago.)
Speed of data retrieval is only partly under a filesystem's control. Access to the actual drive is controlled by the kernel, which is why they've done this anticipatory scheduler for Linux 2.6. And speed can be improved by improving a filesystem's implementation. So filesystem speed is not a trump card. It may factor in choice of filesystem, but it's not an automatic reason to jump ship.
It's not clear what you mean by security. If you mean ACLs and stuff, they're already here. (And the stuff in the article shows how ACLs will be implemented on Reiser.) If you mean data encryption, that's here too. And it's never been the case that users could evesdrop on other users' data retrival.
The things they talk about in the article are things that can't be achieved with other filesystems, not things that can be improved in filesystems. Different kind of article.
This article doesn't seem very religious to me. It outlines what a sharecropper is, why it's bad to be one, and what the alternative is. It suggests that the web platform is not a sharecropping platform, and that it is the best way to avoid getting caught in the sharecropping trap.
I think parts of it are wrong. For example, the web platform is virtually owned by Microsoft. And remember that fuss when MS started giving Opera faulty stylesheets?
Other parts are too vague-- Mac OS X uses fork() and bash.
The whole article is certainly tinged with Bray's bias, but I don't know if "religious" is the right way to describe it.
Providing an authority context in the message solves the problem by putting the burden on vendors. Remember, vendors were s'posed to be avoiding this problem already, by using a non-privelaged UI (like, say, SSH does).
Since vendors don't place a high enough priority on security, it seems like someone is going to have to take care of it for them. If a program wants to accept messages other programs it should declare so explicitly.
Otherwise, what's to prevent a trojan from using QuickBooks to find out your credit card number? Both programs probably have the same privilages, but QuickBooks has access to data that no other program should have. Ad hoc scripting, by definition, permits this possibility.
Finally, I seriously question the value of accepting messages from other programs that cause you to execute a function of the other program's choosing. I can't see any legitimate use for this that justifies the risk.
AFAICT, the model could be "fixed" by preventing applications from sending events to unrelated applications. (You'd need to permit threads and processes to send events to the thrreads and processes that spawned them, I guess.) Of course, this only works if events aren't supposed used for general IPC.
In our code, there are very few debug conditionals (fewer than 20 of 131438 lines of code). We just use debugpf()-- in debug mode, that's another name for fprintf(STDERR,...), and in release builds, that's a noop.
Typdedefs and templates can probably pinch-hit for macros for debugging purposes, but it could be ugly.
And there are some things (especially with predefined macros like __LINE__ ) that only macros can achieve.
I'm just saying the debugging doesn't automatically trump the desire to kill the preprocessor.
You would then use an -I compiler directive to use the appropriate header for your build. Sutter used the example of multi-platform builds, and the technique applies even better there.
Note that DebugMemAllocator and StandardMemAllocator do not have to be defined in tools.h
While it may be easy to change the from/return fields, spammers can't use that power. In order to bypass a whitelist, they'd need to know what addresses were on the whitelist. Then they could send "from" that address.
I agree that a from address isn't proof of identity. It would be great if we could make PGP the default email format of the world. But that's a separate issue. We don't need proof of identity for a whitelist, just proof that the sender knows what email addresses are accepted by you.
Also, I believe you don't want fingerprints, because they don't prove that the email was composed or sent by the they key owner.
Any spammer who knows the fingerprint can use it in their own messages. Instead, you want messages to be signed with PGP, and checked against a public-key whitelist. This will (virtually) prove that a message was sent by someone on the whitelist.
Well, a contract can be dissolved by mutual agreement by both parties. I don't know the legalities, but it does suggest that if the author also declares the contract null, (and the company basically has done that already) he can then go after the company for bigger bux.
I don't speak German, but I do know C: Some possible translations of the German programming terms Kettenabfrage (chained conditions?) sounds like switch statements. Bitmuster (bit patterns ?) sounds like bitmasks
You misinterpret. Let's say 5% of people with brown eyes have blond hair. Let's say 10% of people with blue have blond hair. A blue-eyed person is more likely to have blond hair than a brown-eyed person. Even though it's only a 10% chance.
So you're suggesting that Brazilian software houses might export their programming to lower-cost foreign workers? I suppose they might, but the gov't could make their contracts dependent on local labour being used. If you're modifying gnome-terminal, you can do that, 'cause you have the code. If you want changes to Windows Explorer, how do you get that at all?
I'll follow the author and call the originating Torrent client a "server" but it's not really.
There are a couple of unjustified assumption here.
One is that the "server" can only serve one "client" at a time. This isn't a justified assumption. Several "client/servers" can download from a given Torrent "client/server" at once.
The second assumption is that all clients join simultaneously. This circumstance is theoretically possible, but is pretty damned unlikely.
The third assumption is that all clients can download at the same rate. I'm going to stipulate this for now, because I don't want to complicate things too much.
If we assume a server can serve more than one client simultaneously, and that clients join at least one block apart, it goes like this:
Alice joins first and downloads 2 blocks. Bob joins next, and downloads Alice's two blocks, plus two from the "server". At the same time, Alice downloads another two blocks from the server.
Bob goes on to download 12 blocks from Alice and 12 from Alice. At the same time, Alice downloads 12 blocks from Bob and 12 from the server.
When Charles joins, he downloads 14 blocks from Alice, 14 from Bob, and 14 from the server.
See? If you assume start times are separated by at least one block, it doesn't matter that you can't download block Q from Alice before Alice finishes downloading it. You download it from Bob, Charles, or the server, or you download a different block.
The net upload capacity of a Torrent is equal to the net upload capacity of clients that have downloaded one block. The net upload capacity of konspire networks is equal to the net upload capacity of clients that have received a complete upload.
Bandwidth disparities are a separate problem. With Bittorrent, everyone's upload and download capacities are used to the max. With konspire, it's possible to have a T1 download from a 14.4, while another T1 uploads to a 14.4. This problem could be reduced by dividing files into --wait for it-- blocks and allowing --wait for it -- all clients to use all servers.
Konspire is a neat idea, but I don't think it's technologically superior to a cron job that runs this: killall btdownloadheadless; btdownloadheadless --url http://example.com/latesttorrent.bt
Does anyone have info on the required ports? The FAQ and wiki aren't very helpful. They say your network admin should set up a tunnel, but don't tell the network admin how to set up a tunnel!
Slashdot Mirror
No, this is a newer set of benchmarks.
As soon as you use someone else's hardware, you're necessarily risking your SSH key. You don't know whether there's a hardware keylogger. You don't know whether there's nastyware deliberately or accidentally installed. But security is never absolute anyhow.
The Rush CD IS louder. Because the compression makes its average amplitude greater.
And really, I think it's done because when you're listening to the radio, you often aren't giving it your full attention. You don't want something with loads of dynamic range for background music.
Maybe that's the point, that:
1. (a few) cyborgs do exist.
2. They aren't given equal treatment because their prosthetics aren't chosen from necessity.
Of course, "necessity" isn't an absolute-- perception of what is necessary does change. Can you remember when microcomputers weren't necessary? A while ago, huh?
Remember when lefties were forced to use their right hands? Me neither.
According to the email quoted in the article, the release process "still has to go thorough more people".
Apple may have more control of hardware than Microsoft, but I don't believe that's relevent to the choice of software APIs. This isn't about the device driver model, or anything.
If anything, Apple's control is less firm than Microsoft's, because developers don't have to support them, but supporting Windows is pretty well mandatory for many kinds of applications.
Let me vote for standardization. The most convenient interface should expose the recommended set of operations. If there's a demand for the ability to do things the wrong way,
1. It's an opportunity to improve the design of the recommended API so it can accomodate more developers.
2. You can expose a second API for "Bad" operations.
Microsoft seems to be voting for resolution-independence with Longhorn.
Browsers do override CSS pixel settings. At the user's request, Mozilla will scale the text in any web page, and Opera will scale the bitmaps as well as the text.
Of course, scaling web page images would look nicer with vectors...
I dunno. I didn't compare Windows developers to Linux developers.
The Windows GUI hands a lot of control to the developer. They can't be trusted with that power. They do stupid things like writing GUIs with system privileges.
There are big differences between the output of a paid Windows development team and a volunteer open-source developer, but they're not a different species. They may even be the same person at work and at play.
In any case, I'm saying a well-designed API is hard to use wrong and easy to use right.
In other words, it's up to the app developer to base their UI on the dynamic System Properties rather than on fixed values
You say that like it's a good thing.
Time and time again, Windows developers have shown they can't be trusted to future-proof their apps.
Anyhow, using bitmaps for UI is an optimization that has overstayed its welcome. Vectors are far cooler.
The only reason bitmaps were better in the old days is that screen resolution was universally crappy. Back in the day, we had 320x200, and we were grateful. (Apparently, there was even a CGA 160x100 high-colour mode.) We had to target every pixel, because a difference of one pixel was huge.
The monitor I'm using right now supports 1600x1200, but I'm running at 1280x960 because I don't want everything to be tiny. This is a travesty. Resolution shouldn't affect size, just detail. With OS X, that's how it works.
There's always another way; I produce PDF files using PDFLib. They most definitely look the same every time.
As the poster noted, it's possible to run your filters in user space, not kernel space, so buffer overflows and segfaults should be sources of irritation, not sources of vulnerabilities.
None of the reasons you give (speed, security, error correction) are reaons to change systems. Error correction is handled by media-- that is, hard disks-- these days. (See that article "You Don't Know Jack about Hard Disks" from a day or so ago.)
Speed of data retrieval is only partly under a filesystem's control. Access to the actual drive is controlled by the kernel, which is why they've done this anticipatory scheduler for Linux 2.6. And speed can be improved by improving a filesystem's implementation. So filesystem speed is not a trump card. It may factor in choice of filesystem, but it's not an automatic reason to jump ship.
It's not clear what you mean by security. If you mean ACLs and stuff, they're already here. (And the stuff in the article shows how ACLs will be implemented on Reiser.) If you mean data encryption, that's here too. And it's never been the case that users could evesdrop on other users' data retrival.
The things they talk about in the article are things that can't be achieved with other filesystems, not things that can be improved in filesystems. Different kind of article.
This article doesn't seem very religious to me. It outlines what a sharecropper is, why it's bad to be one, and what the alternative is. It suggests that the web platform is not a sharecropping platform, and that it is the best way to avoid getting caught in the sharecropping trap.
I think parts of it are wrong. For example, the web platform is virtually owned by Microsoft. And remember that fuss when MS started giving Opera faulty stylesheets?
Other parts are too vague-- Mac OS X uses fork() and bash.
The whole article is certainly tinged with Bray's bias, but I don't know if "religious" is the right way to describe it.
Providing an authority context in the message solves the problem by putting the burden on vendors. Remember, vendors were s'posed to be avoiding this problem already, by using a non-privelaged UI (like, say, SSH does).
Since vendors don't place a high enough priority on security, it seems like someone is going to have to take care of it for them. If a program wants to accept messages other programs it should declare so explicitly.
Otherwise, what's to prevent a trojan from using QuickBooks to find out your credit card number? Both programs probably have the same privilages, but QuickBooks has access to data that no other program should have. Ad hoc scripting, by definition, permits this possibility.
Finally, I seriously question the value of accepting messages from other programs that cause you to execute a function of the other program's choosing. I can't see any legitimate use for this that justifies the risk.
AFAICT, the model could be "fixed" by preventing applications from sending events to unrelated applications. (You'd need to permit threads and processes to send events to the thrreads and processes that spawned them, I guess.) Of course, this only works if events aren't supposed used for general IPC.
In our code, there are very few debug conditionals (fewer than 20 of 131438 lines of code). ...), and in release builds, that's a noop.
We just use debugpf()-- in debug mode, that's another name for fprintf(STDERR,
Typdedefs and templates can probably pinch-hit for macros for debugging purposes, but it could be ugly.
And there are some things (especially with predefined macros like __LINE__ ) that only macros can achieve.
I'm just saying the debugging doesn't automatically trump the desire to kill the preprocessor.
Herb Sutter's response is that you shouldn't be sprinkling #ifdefs throughout your program. Instead, you should do something like this:
///Lots of debugging code here
---debug/tools.h---
typedef DebugMemAllocator MemAllocator;
void func1();
void func1()
{
}
---standard/tools.h---
typedef StandardMemAllocator MemAllocator;
inline void func1()
{;}//does nothing
You would then use an -I compiler directive to use the appropriate header for your build. Sutter used the example of multi-platform builds, and the technique applies even better there.
Note that DebugMemAllocator and StandardMemAllocator do not have to be defined in tools.h
While it may be easy to change the from/return fields, spammers can't use that power. In order to bypass a whitelist, they'd need to know what addresses were on the whitelist. Then they could send "from" that address.
I agree that a from address isn't proof of identity. It would be great if we could make PGP the default email format of the world. But that's a separate issue. We don't need proof of identity for a whitelist, just proof that the sender knows what email addresses are accepted by you.
Also, I believe you don't want fingerprints, because they don't prove that the email was composed or sent by the they key owner.
Any spammer who knows the fingerprint can use it in their own messages. Instead, you want messages to be signed with PGP, and checked against a public-key whitelist. This will (virtually) prove that a message was sent by someone on the whitelist.
Well, a contract can be dissolved by mutual agreement by both parties. I don't know the legalities, but it does suggest that if the author also declares the contract null, (and the company basically has done that already) he can then go after the company for bigger bux.
Who needs public keys for that routine? Just whitelist the appropriate email addresses.
I don't speak German, but I do know C:
Some possible translations of the German programming terms
Kettenabfrage (chained conditions?) sounds like switch statements.
Bitmuster (bit patterns ?) sounds like bitmasks
You misinterpret.
Let's say 5% of people with brown eyes have blond hair. Let's say 10% of people with blue have blond hair. A blue-eyed person is more likely to have blond hair than a brown-eyed person. Even though it's only a 10% chance.
So you're suggesting that Brazilian software houses might export their programming to lower-cost foreign workers? I suppose they might, but the gov't could make their contracts dependent on local labour being used. If you're modifying gnome-terminal, you can do that, 'cause you have the code. If you want changes to Windows Explorer, how do you get that at all?
Sure, but web developers are more likely to use Macs than web surfers.
Yes, it's crap.
I'll follow the author and call the originating Torrent client a "server" but it's not really.
There are a couple of unjustified assumption here.
One is that the "server" can only serve one "client" at a time. This isn't a justified assumption. Several "client/servers" can download from a given Torrent "client/server" at once.
The second assumption is that all clients join simultaneously. This circumstance is theoretically possible, but is pretty damned unlikely.
The third assumption is that all clients can download at the same rate. I'm going to stipulate this for now, because I don't want to complicate things too much.
If we assume a server can serve more than one client simultaneously, and that clients join at least one block apart, it goes like this:
Alice joins first and downloads 2 blocks.
Bob joins next, and downloads Alice's two blocks, plus two from the "server". At the same time, Alice downloads another two blocks from the server.
Bob goes on to download 12 blocks from Alice and 12 from Alice.
At the same time, Alice downloads 12 blocks from Bob and 12 from the server.
When Charles joins, he downloads 14 blocks from Alice, 14 from Bob, and 14 from the server.
See? If you assume start times are separated by at least one block, it doesn't matter that you can't download block Q from Alice before Alice finishes downloading it. You download it from Bob, Charles, or the server, or you download a different block.
The net upload capacity of a Torrent is equal to the net upload capacity of clients that have downloaded one block. The net upload capacity of konspire networks is equal to the net upload capacity of clients that have received a complete upload.
Bandwidth disparities are a separate problem. With Bittorrent, everyone's upload and download capacities are used to the max. With konspire, it's possible to have a T1 download from a 14.4, while another T1 uploads to a 14.4. This problem could be reduced by dividing files into --wait for it-- blocks and allowing --wait for it -- all clients to use all servers.
Konspire is a neat idea, but I don't think it's technologically superior to a cron job that runs this:
killall btdownloadheadless; btdownloadheadless --url http://example.com/latesttorrent.bt
Does anyone have info on the required ports? The FAQ and wiki aren't very helpful. They say your network admin should set up a tunnel, but don't tell the network admin how to set up a tunnel!