The majority of the guests are not going to use the borrow the SMTP server that the hotel uses.
They are typically going to HTTPS to some webmail account.
Good luck getting the headers out of that.
If the hotel has a NAT-ted network, what are they supposed to log? Which 192.168.x.y address had a particular evil-doing port number at a particular time, and match that t a guest?
Europeans are going daft.
Re:No amount of documentation ...
on
Autotools
·
· Score: 1
While you should use portability mechanisms in the code itself, sometimes it is not practical.
The things in are constant expressions, and C (and to a lesser degree C++) have limited flexibilities in metaprogramming based on the values of constant expressions.
If you want to conditionally define something based on a function applied to the values in limits.h, you may have to get access to those values outside of the source and generate a header file with preprocessor symbols.
There is a need for build configuration which tailors some things to the target. Only, there is not a need for crappy build configuration.
Re:No amount of documentation ...
on
Autotools
·
· Score: 1
How you can appease the upstream managers is probably by making being compatible. Name the script "configure" and make it support all the standard options like --prefix, --host, --build and so forth. Support "make install" and the DESTDIR= variable to specify a temporary directory for packaging.
Re:No amount of documentation ...
on
Autotools
·
· Score: 1
I'm discussing cross-compiling, so running the program requires emulation, or else uploading it to the target.
The nm utility is standardized by POSIX and The Single Unix spec, and should be in any reasonable toolchain for a a Unix-like system, including a cross-compiling toolchain.
If you have an "arm-cc" for cross-compiling for arm, then there should be an "arm-nm", as well as "arm-ld" and such.
nm can extract the size of a symbol (i.e how much space it occupies). So for instance if we declare:
int __foo[sizeof (struct abc)];
and compile this to produce a.o file, that.o file contains the symbol __foo along with size information. The size of the storage region __foo tells us how large "struct abc" is for our target system.
We can now use this information to configure something in the build.
I've used this trick, for instance, to determine which integer type is large enough to hold a pointer. (C99 gives us intptr_t, but that creates a C99 dependency).
This is something you can't do at compile time, because in C you can't retarget a typedef based on the value of an expression (even a constant one), and the preprocessor (#if, #ifdef) cannot portably evaluate things like sizeof (void *).
May require a bit of a portability layer to run on some systems.
#!/bin/sh case "$(uname -s)" in Cygwin )
echo "dive for the network cable and yank it out, as fast as you can!"
echo "also, flip the wireless switch to off!"
exit 1;; * )
echo "good to go"
exit 0;; esac
There are only 65536 port numbers, so there is only so thin that you can spread a single IP address. Remember that some clients open many ports. There are also questions of reuse; you can't simply cram the 65536 space close to full. When a TCP connection terminates, you don't want to start reusing the port number right away. It's tricky.
People are not going to be happy to be NAT ed. Will large scale NAT also come with large scale port forwarding? Large scale UPnP? What do you do about port number abuses?
Dynamic DNS goes out the window. People can't have a quasi static IP any more with their own port 80, port 22, port 25 mail server or whatever.
If I were to be NATed, I would not want to pay more than 5 dollars a month for such a crippled connection, regardless of bandwidth. So you will automatically have to sell the service to ten subscribers like me instead of just one to make the same revenue.
As long as I can get non-NAT-ted service somewhere, than that is where I will be.
NAT == CRIPPLED_INTERNET. Impose that next door. Next city. Next country. NIMBY: not in my backyard.
And remember that if EVERYONE is NATted, then nobody can talk to anyone. Because you have to connect somewhere to use the Internet. That means resolving DNS to some IP address.
To reach a DNS server you need an IP address. So the DNS server can't be NATed. That DNS server has to hand you the IP address of a host such as a web server. Are all web servers going to be NAT ed? That means they can't be all on port 80 any more. You are looking at redirects! There will have to be a port 80 service sitting on those NAT nodes, which will intercept web traffic, parse the HTTP request and forward to the appropriate node behind the NAT.
Or else DNS will have to be re-architected so that it returns not only IP's but port numbers, so when you go to www.somewhere.com, it resolves to x.y.z.w:n, and the host x.y.z.w has port n forwarded to the right server.
Basically the advantage of BT is that the popular torrent clients that people like and use have good download management features which gives BT a reputation for good download management.
Both FTP and HTTP have a way to resume an interrupted download, so if you are annoyed by having to start HTTP downloads over again, that is not a reason to switch to Bittorrent.
A FTP or HTTP client could implement the same download management, as well as bandwidth management features as a BT client.
What you don't get with FTP or HTTP is the swarming (obtaining pieces of the data from other downloaders). You also can't download selected portions of an archive: FTP or HTTP make you download a tarball, whereas a torrent can represent a directory structure from which you can pick and choose (since the torrent format reveals which files occupy which blocks).
BT also has better integrity checking than just a whole-file CRC. With HTTP or FTP, you have to validate checksums manually.
BT supports upload and download so you can "pay" for your download by passing it on to others, thus offloading the original seeders. HTTP downloads don't have anything like this; to contribute to the effort, you have to host the file somewhere. If you host the file somewhere, you can't just let the world have 120% of it and then stop; the only ratios you have are whole numbers: let one person download it, let two people download it, etc.
So those would be the main reasons for using BT for getting an OS image: the swarm effect, sharing with flexible upload ratios, picking and choosing archive content, and built-in block-level data integrity.
Defending against monkeys using other monkeys is not security. It's animal control; i.e. safety.
Security means separating authorized humans from unauthorized humans.
Could the monkey distinguish a human being who is authorized to be somewhere from one who is not?
Could it verify someone's identity, validate an ID badge, look up a name in a list of names, check tickets, etc?
If not, that monkey is not a security officer in any reasonable sense of the word.
Re:Autotools do not need a book
on
Autotools
·
· Score: 1
Hi Urban Garlic,
The most important thing to know is that the --prefix argument (for a correctly designed configure script which follows the conventions) indicates the run-time installation directory of the program. I.e. the path given to --prefix may actually be compiled into the program and then used by that program at run-time.
The average free software user compiles the program on the same machine where he will run it. And so the prefix is also the place where the program is copied during "make install".
The default value for --prefix is often/usr/local, for this specific use case.
If you're building a distro or toolchain, you may have to override --prefix to/usr. (Assuming that the programs you are making wll go into/usr/bin,/usr/lib, etc on the target system).
The point is that the prefix has to be correct for the ultimate destination where the software lives.
Of course, when you're preparing a package for another system (perhaps a cross-compiled package, even), and the prefix is/usr, of coures you can't do "make install" because that will try to copy into/usr on the local build system! You must install into some temporary directory (or a "sysroot" directory where you are building up the filesystem image for a target). The way this is done varies from package to package. Some packages accept an extra configure parameter, like --install_dir. Many packages accept a make variable called DESTDIR which is specified on the "make install" command line; the contents of DESTDIR is prepended to the prefix. In some cases you can override the prefix variable itself at install time "make install prefix=...".
Re:Cross-platform, but not cross-compiling
on
Autotools
·
· Score: 1
Indeed, requiring that part of the build takes place on the target machine, or having to emulate it, is an incredibly lame-assed copout.
At Zeugma Systems, I produced an embedded GNU/Linux distro known as Zeugma Linux. The rule of the project was that everything cross-compiles.
No MIPS instruction was emulated during the build.
I took the lessons that I learned, and incorporate them into the small configure scripts that I write by hand, which takes far less effort over the life of the project than dealing with Autotools.
No amount of documentation ...
on
Autotools
·
· Score: 5, Interesting
can compensate for the low quality of this garbage, not to mention its poor performance (some builds spend more time running configure than actually compiling, installing, and tarring up the resulting run-time and devel packages!)
These tools have to be redesigned from the ground up by someone who understands that free software has made large inroads into the embedded world where it needs to be, doh, cross-compiled.
For my own projects, I develop a carefully-crafted configure shell script by hand and recommend everyone do the same.
The script has carefully developed and tested support for (1) cross-compiling, (2) configuring/building in a separate directory, and (3) installation into a temporary package directory.
Furthermore, this script should ONLY test the features that are actually needed by the program. (The program should assume a reasonably modern system; don't bother testing for obscure bugs in System V release 3, okay?) The script should make sure that it tests only header files and compiling with the toolchain that it is given. The configure test programs programs should never accidentally include something in the build machine/usr/include, or link something from/usr/lib!
Configure scripts should never run any program that they compile because it may be the wrong architecture, and they should not have an "if cross compiling" check which disables their features when cross-compiling and substitutes dumb defaults! Quite simply, implement the tests so that cross-compiling is not needed.
For instance, instead of making a C program which outputs values with printf, make it so that the values are used as initializers for static data. Then use the cross-compiling toolchain's "nm" utility to extract the values from the compiled object file. You don't have to run a program to know how wide a (void *) is. Just do "static char size_of_void_star[sizeof (void *)]". Compile it, and then interrogate the.o to discover what is the content of the size of the data region named by size_of_void_star!
Look at the stupid configure script for GNU bash. When crossing, it assumes totally pessimistic values for all checks that can't be done when cross-compiling. Unless you explicitly override the ac_* variables yourself, you get a shell which has no job control! The bash build assumes that your kernel has a tty system dating back to the middle 1980's.
Nobody should dig through a configure script to find out what broken tests they have to override by setting the variables manually.
Shell code should never be generated by m4 macros, let alone ones which frequently change.
Look at the stupidity of thisl. Suppose you want to produce a minimal patch for some open source project that uses autoconf. Suppose that as part of your patch you have to enhance the configure script with some new options. To do that, you have to modify configure.in. But projects ship with the generated configure script. So you want to regenerate that, right? Oops, your version of autoconf is different, and so you get a HUGE diff. Worse yet, the generated configure script breaks!
So people end up with ten different versions of autoconf installed, so they can always run the right one which matches what the configure script was produced with that is in the tarball.
Build configuration from scratch is not difficult. It is easy. Autotools do not simplify anything. They monstrously complicate something which is already simple and doesn't require simplification or automation. Using the Autotools is a false economy. You may think you are getting something for free and saving time, but in the end you will spend more time over the life of your project wrestling with this garbage (and also waste the time of countless other people you don't even know) than if you just carefully wrote a small configure script by hand.
Otherwise it's just an attention-getting overture. They are in the news now, which means that people who have never heard of them are now thinking about visiting.
Just wait, six months from now, everyone will have forgotten about this and they will quietly back down.
I mean, someone could look at it this way. The vendors don't want to compensate you for giving them your cash, by giving you ownership. So, to hell with compensating them for their wares.
The more you treat customers like shit, the more they will rationalize piracy.
A monopoly would mean that you have no choice but Pay Pal if you want to process credit card payments.
Pay Pal does have partnerships with other shady companies. If you're stupid enough to use the services of those companies to set up your business, you are also forced to use Pay Pal.
Well, what you can do is sell the "right to obtain a refund" for the software to whose license you did not agree. The software is not yet yours, but you paid for it. You did not agree to the license, so you are not bound by it. What you do own is the right to a refund, and that is a value you can sell.:):)
Slashdot Mirror
The majority of the guests are not going to use the borrow the SMTP server that the hotel uses.
They are typically going to HTTPS to some webmail account.
Good luck getting the headers out of that.
If the hotel has a NAT-ted network, what are they supposed to log? Which 192.168.x.y address had a particular evil-doing port number at a particular time, and match that t a guest?
Europeans are going daft.
While you should use portability mechanisms in the code itself, sometimes it is not practical.
The things in are constant expressions, and C (and to a lesser degree C++) have limited flexibilities in metaprogramming based on the values of constant expressions.
If you want to conditionally define something based on a function applied to the values in limits.h, you may have to get access to those values outside of the source and generate a header file with preprocessor symbols.
There is a need for build configuration which tailors some things to the target. Only, there is not a need for crappy build configuration.
How you can appease the upstream managers is probably by making being compatible. Name the script "configure" and make it support all the standard options like --prefix, --host, --build and so forth. Support "make install" and the DESTDIR= variable to specify a temporary directory for packaging.
I'm discussing cross-compiling, so running the program requires emulation, or else uploading it to the target.
The nm utility is standardized by POSIX and The Single Unix spec, and should be in any reasonable toolchain for a a Unix-like system, including a cross-compiling toolchain.
If you have an "arm-cc" for cross-compiling for arm, then there should be an "arm-nm", as well as "arm-ld" and such.
nm can extract the size of a symbol (i.e how much space it occupies). So for instance if we declare:
int __foo[sizeof (struct abc)];
and compile this to produce a .o file, that .o file contains the symbol __foo along with size information. The size of the storage region __foo tells us how large "struct abc" is for our target system.
We can now use this information to configure something in the build.
I've used this trick, for instance, to determine which integer type is large enough to hold a pointer. (C99 gives us intptr_t, but that creates a C99 dependency).
This is something you can't do at compile time, because in C you can't retarget a typedef based on the value of an expression (even a constant one), and the preprocessor (#if, #ifdef) cannot portably evaluate things like sizeof (void *).
Add comments to a web page without the permission of the website operators.
http://reframeit.com/
May require a bit of a portability layer to run on some systems.
#!/bin/sh ;; ;;
case "$(uname -s)" in
Cygwin )
echo "dive for the network cable and yank it out, as fast as you can!"
echo "also, flip the wireless switch to off!"
exit 1
* )
echo "good to go"
exit 0
esac
There are only 65536 port numbers, so there is only so thin that you can spread a single IP address. Remember that some clients open many ports. There are also questions of reuse; you can't simply cram the 65536 space close to full. When a TCP connection terminates, you don't want to start reusing the port number right away. It's tricky.
People are not going to be happy to be NAT ed. Will large scale NAT also come with large scale port forwarding? Large scale UPnP? What do you do about port number abuses?
Dynamic DNS goes out the window. People can't have a quasi static IP any more with their own port 80, port 22, port 25 mail server or whatever.
If I were to be NATed, I would not want to pay more than 5 dollars a month for such a crippled connection, regardless of bandwidth. So you will automatically have to sell the service to ten subscribers like me instead of just one to make the same revenue.
As long as I can get non-NAT-ted service somewhere, than that is where I will be.
NAT == CRIPPLED_INTERNET. Impose that next door. Next city. Next country. NIMBY: not in my backyard.
And remember that if EVERYONE is NATted, then nobody can talk to anyone. Because you have to connect somewhere to use the Internet. That means resolving DNS to some IP address.
To reach a DNS server you need an IP address. So the DNS server can't be NATed. That DNS server has to hand you the IP address of a host such as a web server. Are all web servers going to be NAT ed? That means they can't be all on port 80 any more. You are looking at redirects! There will have to be a port 80 service sitting on those NAT nodes, which will intercept web traffic, parse the HTTP request and forward to the appropriate node behind the NAT.
Or else DNS will have to be re-architected so that it returns not only IP's but port numbers, so when you go to www.somewhere.com, it resolves to x.y.z.w:n, and the host x.y.z.w has port n forwarded to the right server.
Good grief, and good luck with that.
Basically the advantage of BT is that the popular torrent clients that people like and use have good download management features which gives BT a reputation for good download management.
Both FTP and HTTP have a way to resume an interrupted download, so if you are annoyed by having to start HTTP downloads over again, that is not a reason to switch to Bittorrent.
A FTP or HTTP client could implement the same download management, as well as bandwidth management features as a BT client.
What you don't get with FTP or HTTP is the swarming (obtaining pieces of the data from other downloaders). You also can't download selected portions of an archive: FTP or HTTP make you download a tarball, whereas a torrent can represent a directory structure from which you can pick and choose (since the torrent format reveals which files occupy which blocks).
BT also has better integrity checking than just a whole-file CRC. With HTTP or FTP, you have to validate checksums manually.
BT supports upload and download so you can "pay" for your download by passing it on to others, thus offloading the original seeders. HTTP downloads don't have anything like this; to contribute to the effort, you have to host the file somewhere. If you host the file somewhere, you can't just let the world have 120% of it and then stop; the only ratios you have are whole numbers: let one person download it, let two people download it, etc.
So those would be the main reasons for using BT for getting an OS image: the swarm effect, sharing with flexible upload ratios, picking and choosing archive content, and built-in block-level data integrity.
Defending against monkeys using other monkeys is not security. It's animal control; i.e. safety.
Security means separating authorized humans from unauthorized humans.
Could the monkey distinguish a human being who is authorized to be somewhere from one who is not?
Could it verify someone's identity, validate an ID badge, look up a name in a list of names, check tickets, etc?
If not, that monkey is not a security officer in any reasonable sense of the word.
Hi Urban Garlic,
The most important thing to know is that the --prefix argument (for a correctly designed configure script which follows the conventions) indicates the run-time installation directory of the program. I.e. the path given to --prefix may actually be compiled into the program and then used by that program at run-time.
The average free software user compiles the program on the same machine where he will run it. And so the prefix is also the place where the program is copied during "make install".
The default value for --prefix is often /usr/local, for this specific use case.
If you're building a distro or toolchain, you may have to override --prefix to /usr. (Assuming that the programs you are making wll go into /usr/bin, /usr/lib, etc on the target system).
The point is that the prefix has to be correct for the ultimate destination where the software lives.
Of course, when you're preparing a package for another system (perhaps a cross-compiled package, even), and the prefix is /usr, of coures you can't do "make install" because that will try to copy into /usr on the local build system! You must install into some temporary directory (or a "sysroot" directory where you are building up the filesystem image for a target). The way this is done varies from package to package. Some packages accept an extra configure parameter, like --install_dir. Many packages accept a make variable called DESTDIR which is specified on the "make install" command line; the contents of DESTDIR is prepended to the prefix. In some cases you can override the prefix variable itself at install time "make install prefix=...".
Indeed, requiring that part of the build takes place on the target machine, or having to emulate it, is an incredibly lame-assed copout.
At Zeugma Systems, I produced an embedded GNU/Linux distro known as Zeugma Linux. The rule of the project was that everything cross-compiles.
No MIPS instruction was emulated during the build.
I took the lessons that I learned, and incorporate them into the small configure scripts that I write by hand, which takes far less effort over the life of the project than dealing with Autotools.
can compensate for the low quality of this garbage, not to mention its poor performance (some builds spend more time running configure than actually compiling, installing, and tarring up the resulting run-time and devel packages!)
These tools have to be redesigned from the ground up by someone who understands that free software has made large inroads into the embedded world where it needs to be, doh, cross-compiled.
For my own projects, I develop a carefully-crafted configure shell script by hand and recommend everyone do the same.
The script has carefully developed and tested support for (1) cross-compiling, (2) configuring/building in a separate directory, and (3) installation into a temporary package directory.
Furthermore, this script should ONLY test the features that are actually needed by the program. (The program should assume a reasonably modern system; don't bother testing for obscure bugs in System V release 3, okay?) The script should make sure that it tests only header files and compiling with the toolchain that it is given. The configure test programs programs should never accidentally include something in the build machine /usr/include, or link something from /usr/lib!
Configure scripts should never run any program that they compile because it may be the wrong architecture, and they should not have an "if cross compiling" check which disables their features when cross-compiling and substitutes dumb defaults! Quite simply, implement the tests so that cross-compiling is not needed.
For instance, instead of making a C program which outputs values with printf, make it so that the values are used as initializers for static data. Then use the cross-compiling toolchain's "nm" utility to extract the values from the compiled object file. You don't have to run a program to know how wide a (void *) is. Just do "static char size_of_void_star[sizeof (void *)]". Compile it, and then interrogate the .o to discover what is the content of the size of the data region named by size_of_void_star!
Look at the stupid configure script for GNU bash. When crossing, it assumes totally pessimistic values for all checks that can't be done when cross-compiling. Unless you explicitly override the ac_* variables yourself, you get a shell which has no job control! The bash build assumes that your kernel has a tty system dating back to the middle 1980's.
Nobody should dig through a configure script to find out what broken tests they have to override by setting the variables manually.
Shell code should never be generated by m4 macros, let alone ones which frequently change.
Look at the stupidity of thisl. Suppose you want to produce a minimal patch for some open source project that uses autoconf. Suppose that as part of your patch you have to enhance the configure script with some new options. To do that, you have to modify configure.in. But projects ship with the generated configure script. So you want to regenerate that, right? Oops, your version of autoconf is different, and so you get a HUGE diff. Worse yet, the generated configure script breaks!
So people end up with ten different versions of autoconf installed, so they can always run the right one which matches what the configure script was produced with that is in the tarball.
Build configuration from scratch is not difficult. It is easy. Autotools do not simplify anything. They monstrously complicate something which is already simple and doesn't require simplification or automation. Using the Autotools is a false economy. You may think you are getting something for free and saving time, but in the end you will spend more time over the life of your project wrestling with this garbage (and also waste the time of countless other people you don't even know) than if you just carefully wrote a small configure script by hand.
Japan just has to order some children's toys.
If it's on the periodic table, you can find it in there.
Otherwise it's just an attention-getting overture. They are in the news now, which means that people who have never heard of them are now thinking about visiting.
Just wait, six months from now, everyone will have forgotten about this and they will quietly back down.
No, EQ measures how much midrange you have cut or boosted on your guitar.
What engineers have is the ability to immigrate, because they can work internationally. And earn a decent living, even in spite of poor English.
Think about it.
A domain is a node in the DNS namespace. How does that get infected?
If a web server hosts 20 domains, and is infected, does that count as 20 infections?
"Web site", "domain" and "host" are not interchangeable.
I suspect that 18% are just incredibly daft, and can be led into answering a question such that they appear to support geocentrism.
"Do you think the Earth is the center of the universe?"
"Uh, yes?"
"Might the Sun not be center of the universe?"
"Uh, oh yeah, sure, yes."
We dont know Indian work place laws or legal system.
It's Indiana, the U.S. City, not the country of India.
No, they don't. The employer is not a criminal court of law. Rational suspicion of wrongdoing is enough to can someone.
And if he can't afford a lawyer to defend against this, what are the odds he can come up with one for a wrongful dismissal action?
You are working for assholes who are assuming that the registration is yours even though you explained the situation.
Who would be dumb enough to register a domain which infringes on his employer's trademark somehow, and using his real name?
What for?
I mean, someone could look at it this way. The vendors don't want to compensate you for giving them your cash, by giving you ownership. So, to hell with compensating them for their wares.
The more you treat customers like shit, the more they will rationalize piracy.
If you don't really own the stuff when you buy it, it follows that you aren't really stealing it when you copy it. :)
A monopoly would mean that you have no choice but Pay Pal if you want to process credit card payments.
Pay Pal does have partnerships with other shady companies. If you're stupid enough to use the services of those companies to set up your business, you are also forced to use Pay Pal.
That is not a monopoly.
Hard to have sympathy for people who are incapable of the simple act of Googling "X sucks" when contemplating doing business with X.
Well, what you can do is sell the "right to obtain a refund" for the software to whose license you did not agree. The software is not yet yours, but you paid for it. You did not agree to the license, so you are not bound by it. What you do own is the right to a refund, and that is a value you can sell. :) :)