Wikipedia:Reference desk/Archives/Computing/2010 October 6

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

October 6

Internet domain seized

I came across this link on a forum, Movies Links.tv, and there is an interesting seizure notice. I have never seen a website seized by the US government (or any government for that matter) before. Is this a new thing we should be expecting now? My understanding is that the Combating Online Infringement and Counterfeits Act bill is still being proposed for hearing. I'm not sure what my question is, but I suppose it could be: Was the seizure of movies-links.tv a legal or ethical move on the part of the US government (despite however illegal and unethical the site may have originally been)? I'm not looking for opinions, I was hoping for some substantial explanation of what this website seizure was, and if we should expect more of it in the near future. thank you. Nimbuskindling (talk) 18:05, 6 October 2010 (UTC)

I think you're in the wrong section; this is a reference desk about using computers, not for legal questions. —Jeremy ^{(v^_^v PC/SP is a show-trial!)} 18:09, 6 October 2010 (UTC)

I don't see a problem with the question. The computer desk if for "Computing, information technology, electronics, software and hardware", and this question surely qualifies as that. 82.44.55.25 (talk) 18:21, 6 October 2010 (UTC)

Reread the question: Was the seizure of movies-links.tv a legal or ethical move on the part of the US government (despite however illegal and unethical the site may have originally been)? That is explicitly a legal question. —Jeremy ^{(v^_^v PC/SP is a show-trial!)} 18:53, 6 October 2010 (UTC)

A legal question about a computer related topic. Websites, domain names, servers etc all fall under the computer desk. Note that the question is not asking for legal advice, which would be against the guidelines. 82.44.55.25 (talk) 19:02, 6 October 2010 (UTC)

It's not that new. It happened to The iSONEWS a few years back. It's a bit of a silly show of force to confiscate a domain name, if you ask me. AS web-site is almost entirely independent of it's domain. The iSONEWS team just registered a new domain and kept on rolling.

I notice that http://www.movies-links.tv.info is a valid domain. Perhaps it's run by the same people? APL (talk) 18:24, 6 October 2010 (UTC)

It is impossible to evaluate on face-value whether that notice is legitimate. For all we know, the owner of the website might have put it up there as a statement, or publicity stunt, or so on. If you're particularly curious, you could presumably contact the U.S. Attorney's Office for the Southern District of New York: here is their web page, and ask them to verify whether they are responsible for this seizure. (Addendum - after edit-conflict, Looie496 seems to have provided a relevant corroborating link from the D.o.J.) Nimur (talk) 18:27, 6 October 2010 (UTC)

You can find an explanation of the seizure in this document. Looie496 (talk) 18:27, 6 October 2010 (UTC)

Thanks to everyone for their answers. I definitely was not asking for legal advice, but I was merely curious what was going on. Looie496, the PDF answers any questions I may have had, and actually gives me several more. But that would be beyond the scope of objectivity. I really appreciate everyone's comments, thank you. Nimbuskindling (talk) 19:45, 6 October 2010 (UTC)

The site was seized by U.S. Immigration and Customs Enforcement (ICE) as part of their “Operation In Our Sites”.Smallman12q (talk) 23:57, 6 October 2010 (UTC)

Makefile/library compilation issue

Hi. I'm working on a project that requires compiling C and Fortran source code (in $proj/src/core, into a static library, and then link driver routines (e.g. in $proj/src/serial to the library. I'm also trying to place all the object files in a $proj/obj directory, and Fortran module files in $proj/mod. I got that working all right, but for some reason, make is compiling everything all the time, even when no changes have been made to the sources.

The Makefile I'm using is the following, with $(INSTALL_DIR) being $proj above:

Makefile Version 1

include ../../Makefile.in
#This is the src/core Makefile

OBJS= /* f90 object files */
CFILES=  /* c object files */
LIBNAME=libcore.a

# Common compiler options for all target combinations
CFLAGS= $(CFLAGS_ALL)
FCFLAGS= $(FCFLAGS_ALL) 
INCLUDES=$(HDF_INCLUDES) $(PARMETIS_INCLUDES)
LFLAGS=$(HDF_LIB) $(PARMETIS_LIB)

# Output path
INSTALL_DIR=$(shell pwd | sed -e 's/\/src\/core.*$///')
OBJPATH=$(INSTALL_DIR)/obj/core
MODPATH=$(INSTALL_DIR)/mod/core
LIBPATH=$(INSTALL_DIR)/lib

# Attach debugging compiler options for debug configurations
debug debug-nohdf: FCFLAGS+=$(FCFLAGS_DEBUG)

# Override INCLUDES AND LFLAGS and attach the NOHDF preprocessor directive
# for the nohdf configurations
nohdf debug-nohdf: INCLUDES=$(PARMETIS_INCLUDES) 
nohdf debug-nohdf: FCFLAGS+=$(FCFLAGS_NOHDF) 
nohdf debug-nohdf: LFLAGS=$(PARMETIS_LIB)

# Attach optimazation compiler options for opt configuration
opt: FCFLAGS+=$(FCFLAGS_OPT)

$(LIBNAME):$(CFILES) $(OBJS) Makefile
	cd $(OBJPATH); $(AR) $(ARFLAGS) $(LIBPATH)/$(LIBNAME) $(OBJS) $(CFILES); $(RL) $(LIBPATH)/$(LIBNAME)

debug debug-nohdf nohdf opt: $(LIBNAME)

%.o : %.F90
	$(F90) $(FCFLAGS) $(INCLUDES) $(MODFLAG)$(MODPATH) -c $*.F90 -o $(OBJPATH)/$*.o $(LFLAGS)

%.o : %.c
	$(CC) $(CFLAGS) $(INCLUDES) -c $*.c -o $(OBJPATH)/$*.o $(LFLAGS)
clean:
	-cd $(OBJPATH); rm *.o
	-cd $(MODPATH); rm *.mod
	-cd $(LIBPATH); rm $(LIBNAME)

Am I doing something that is clearly confusing Make? Titoxd^{(?!? - cool stuff)} 21:20, 6 October 2010 (UTC)

What command are you using to run make ? If you make libcore.a, do you get a different result than if you check the status for a specific file, e.g., make (specific_file).o? Nimur (talk) 21:28, 6 October 2010 (UTC)

Also - this is probably the problem: your rule is actually for %.o but it creates a file called $(OBJPATH)/$*.o. Switch your rule to:

$(OBJPATH)/%.o : %.F90
	$(F90) $(FCFLAGS) $(INCLUDES) $(MODFLAG)$(MODPATH) -c $*.F90 -o $(OBJPATH)/$*.o $(LFLAGS)


$(OBJPATH)/%.o : %.c
	$(CC) $(CFLAGS) $(INCLUDES) -c $*.c -o $(OBJPATH)/$*.o $(LFLAGS)

Technically, this means that your rule never creates the file it thinks it's defining (so even after compiling, ./somefile.o doesn't exist in the current directory). Consider using $@ for the output to guarantee that your rule actually creates the file that it's defining. Nimur (talk) 21:31, 6 October 2010 (UTC)

I'm just using make and make debug as targets. Let me try the $(OBJPATH) fix. Where would I put the $@? (I'm relatively new with Makefiles) Titoxd^{(?!? - cool stuff)} 21:35, 6 October 2010 (UTC)

Sorry, I should have been explicit:

$(OBJPATH)/%.o : %.F90
	$(F90) $(FCFLAGS) $(INCLUDES) $(MODFLAG)$(MODPATH) -c $*.F90 -o $@ $(LFLAGS)


$(OBJPATH)/%.o : %.c
	$(CC) $(CFLAGS) $(INCLUDES) -c $*.c -o $@ $(LFLAGS)

This $@ expands to the rule target (in other words, the correctly and fully expanded version of $(OBJPATH)/%.o). By always using $@, you can guarantee that any rule that runs will successfully create the target it intended to create. In your case, it was a mismatch between the rule-name and the actual output file-name (rather, the location of the output file). So no rule was ever "satisfied," and required a re-build every time. Nimur (talk) 21:37, 6 October 2010 (UTC)

(edit conflict) Hmm. If I add the OBJPATH to the rule, the $(LIBNAME) rule never sees $(OBJPATH)/somefile.o, since it is looking for somefile.o in the current directory. Should I replace $(LIBNAME) with

$(LIBNAME):$(OBJPATH)/$(CFILES) $(OBJPATH)/$(OBJS) Makefile
	cd $(OBJPATH); $(AR) $(ARFLAGS) $(LIBPATH)/$(LIBNAME) $(OBJS) $(CFILES); $(RL) $(LIBPATH)/$(LIBNAME)

or is there a less kludgy way of doing it? Titoxd^{(?!? - cool stuff)} 21:39, 6 October 2010 (UTC)

The less kludgey way is to define a SRCPATH, just like you have for your OBJPATH. Then, any dependency on a .c or .f90 file should be replaced with $(SRCDIR)/file.c or $(SRCDIR)/file.f90. Some people like to use the short variable names "S", "O", and "B", for "source", "object", and "build" directories, since these variables are used so often. Nimur (talk) 21:42, 6 October 2010 (UTC)

\r Ok, so what I have now is

Makefile Version 2

include ../../Makefile.in
#This is the src/core Makefile

OBJS= /* f90 object files */
CFILES=  /* c object files */
LIBNAME=libcore.a

# Common compiler options for all target combinations
CFLAGS= $(CFLAGS_ALL)
FCFLAGS= $(FCFLAGS_ALL) 
INCLUDES=$(HDF_INCLUDES) $(PARMETIS_INCLUDES)
LFLAGS=$(HDF_LIB) $(PARMETIS_LIB)

# Output path
INSTALL_DIR=$(shell pwd | sed -e 's/\/src\/core.*$///')
SRCPATH=$(INSTALL_DIR)/src/core
OBJPATH=$(INSTALL_DIR)/obj/core
MODPATH=$(INSTALL_DIR)/mod/core
LIBPATH=$(INSTALL_DIR)/lib

# Attach debugging compiler options for debug configurations
debug debug-nohdf: FCFLAGS+=$(FCFLAGS_DEBUG)

# Override INCLUDES AND LFLAGS and attach the NOHDF preprocessor directive
# for the nohdf configurations
nohdf debug-nohdf: INCLUDES=$(PARMETIS_INCLUDES) 
nohdf debug-nohdf: FCFLAGS+=$(FCFLAGS_NOHDF) 
nohdf debug-nohdf: LFLAGS=$(PARMETIS_LIB)

# Attach optimazation compiler options for opt configuration
opt: FCFLAGS+=$(FCFLAGS_OPT)

$(LIBNAME):$(CFILES) $(OBJS) Makefile

#$(PROJ):$(CFILES) $(OBJS)
#	$(F90) $(FCFLAGS) $(INCLUDES) -o $(PROJ) $(CFILES) $(OBJS) $(LFLAGS)

nohdf debug debug-nohdf opt opt-nohdf: $(LIBNAME)
	cd $(OBJPATH); $(AR) $(ARFLAGS) $(LIBPATH)/$(LIBNAME) $(OBJS) $(CFILES); $(RL) $(LIBPATH)/$(LIBNAME)

$(OBJPATH)/%.o : %.F90
	$(F90) $(FCFLAGS) $(INCLUDES) $(MODFLAG)$(MODPATH) -c $(SRCPATH)/$*.F90 -o $@ $(LFLAGS)

$(OBJPATH)/%.o : %.c
	$(CC) $(CFLAGS) $(INCLUDES) -c $(SRCPATH)/$*.c -o $@ $(LFLAGS)


clean:
	-rm $(LIBNAME);
	-cd $(OBJPATH); rm *.o
	-cd $(MODPATH); rm *.mod
	-cd $(LIBPATH); rm $(LIBNAME)

Now it dies while trying to link the second member of $OBJS (No rule to make target `file2.o', needed by `libcore.a'. Stop.) What did I screw up? Titoxd^{(?!? - cool stuff)} 21:56, 6 October 2010 (UTC)

Remember, you don't actually have a file called file2.o - you only have $(OBJDIR)/file2.o. So your dependencies need to be updated: libcore.a depends on $(OBJS), so your definition for that should be qualified.

OBJS= $(OBJDIR)/file1.o $(OBJDIR)/file2.o   /* ... and so on */

Nimur (talk) 22:06, 6 October 2010 (UTC)

I see. I recall that there is a way of recursively prepending the fully qualified name for the dependencies. How would I go about doing that? Titoxd^{(?!? - cool stuff)} 22:20, 6 October 2010 (UTC)

I think you are correct; I can not recall off the top of my head what it is. These text-functions and string-replacement utilities are available in GNU Make; you can probably use them. Nimur (talk) 23:35, 6 October 2010 (UTC)

It did: I just used this:

# Add a prefix to F90 and C objects
OBJS:=$(patsubst %,$(OBJPATH)/%,$(OBJS))
CFILES:=$(patsubst %,$(OBJPATH)/%,$(CFILES))

I also switched OBJS and CFILES from recursively expanded variables to simply expanded variables throughout (:= instead of =) and that did the trick. Titoxd^{(?!? - cool stuff)} 02:32, 7 October 2010 (UTC)

This may not be a useful comment, but your life would be vastly simplified if you could set up an environment that allows you to use GNU autotools instead of writing Makefiles. There is a significant learning curve, but once you are past it, writing Makefile.am's instead of Makefile's saves an infinite amount of time and head-scratching. Looie496 (talk) 03:08, 7 October 2010 (UTC)

I thought about that, but I can't justify making Perl a prerequisite for compilation, when the program doesn't do anything with Perl. I've had nightmares with autotools in another project, so I'm also not too excited about using them. Titoxd^{(?!? - cool stuff)} 11:07, 7 October 2010 (UTC)

Laptops?

So my PC's finally on its last legs, and my mum and da are getting me a laptop. This is both cause for rejoicing and confusion. I don't know much about why one PC is better than another. Which brings me to my question: Anyone willing to give me input on my choices? I'll mostly be using the PC for Web browsing (a ton of that) and word processing (also a ton of that), but I'll also stream the occasional movie/TV show off Netflix or Hulu. I'm getting it at Fry's, so I'm limited to their inventory. I only have a few hours before I lose my chance to pick a laptop up today, so here goes:

1. Laptop number one is described as a "Toshiba S7040 17.3" notebook -- Powered by AMD Athlon II P340 Dual-core Processor with 4GB memory and 320GB Hard drive. It's called the Toshiba Satellite. I don't know what the heck AMD Athlon means, but I do want a dual-core processor. It'll cost me 530 bucks, not including tax
2. Laptop number two is a Lenovo G560 15.6" notebook with Intel Pentium Dual Core processor P6100. It'll cost me 500 bucks, not including tax.
3. Laptop number three is a Lenovo G550 15.6" notebook featuring an Intel Pentium Dual Core Processor T4500 with 4GB memory and 250GB hard drive. It'll cost me 515 bucks, not including tax.

Which one do I pick? --- cymru lass ^{(hit me up)}⁄_{(background check)} 22:52, 6 October 2010 (UTC)

Either 3 or 1, in my opinion Sir Stupidity (talk) 22:58, 6 October 2010 (UTC)

One thing to consider: weight. Will you be hauling the thing around (school/college/work/friends)? Although the Fry's pages don't seem to give the weight, it's likely the Toshiba (being a bigger screen) (and thus a bigger roomier case) will weight more than the two smaller Lenovos. Having bought a large heavy laptop, I bitterly regretted that when I realised I'd spend an hour or so each day carrying the thing about. Conversely the bigger screen is, well, bigger, so probably a bit nicer to work on, and to play games and view DVDs. If you're not going to be moving the thing around, then the weight isn't an issue, and the big screen is a welcome thing - but if you'll be carrying it everywhere, a heavy laptop can feel like a curse. 87.112.51.188 (talk) 22:59, 6 October 2010 (UTC)

I definitely won't be carrying it around. I'm much too clumsy for that sort of thing; I would probably break it. My friend's telling me to go with either 2 or 1. Both 2 and 1 have 320 GB hard drives, and I'm notorious for taking up a lot of hard drive So I guess it's more of a 1 vs 2 thing now. --- cymru lass ^{(hit me up)}⁄_{(background check)} 23:12, 6 October 2010 (UTC)

I had a Toshiba notebook for a while and liked it, for what the brand is worth. I've never had a Lenovo. Part of this will be the physical feel of the laptops, as 87 above wrote. Glad to see all your choices have 4GB RAM. If you want to look up CPU benchmarking you may have some luck at tomshardware.com or possibly anandtech. Comet Tuttle (talk) 23:19, 6 October 2010 (UTC)

Both brands are respectable; the CPU issue is a non-issue. As you don't care about weight, the big screen is better. One word of warning: make sure you get an unopened one; if they only have ones that have been returned and restocked, simply don't buy (no matter how well they claim they've checked the return). 87.112.51.188 (talk) 23:33, 6 October 2010 (UTC)

Agreed. Both brands are good. But I'd be worried about the speed of their hard drives -- only 5400 RPM. That'll slow them down more than the memory or CPU. You could just buy a 320 GB, 7200 RPM drive separately and put it into the laptop: [1]. Also, the Toshiba comes with the 64-bit version of Windows 7, meaning you'll need 64-bit drivers for any printers or peripherals. If they're old devices, 64-bit drivers may not be available.--Best Dog Ever (talk) 23:53, 6 October 2010 (UTC)

Thanks for all your advice, guys I'm getting the Toshiba. --- cymru lass ^{(hit me up)}⁄_{(background check)} 00:03, 7 October 2010 (UTC)

FWIW I wouldn't touch a Lenovo with a barge pole. We have to use them at work and have no end of trouble. I'm sure they have some fine models, but not the models I've come across. My last one was so bad I ended up sending it back to head office and buying my own laptop for work use out of my own money (HP for the record). From very limited experience Toshibas seem to be OK. --jjron (talk) 16:35, 8 October 2010 (UTC)