Compatibility for ThinkPad T500 2055

5 réponses [Dernière contribution]
Hors ligne
A rejoint: 06/17/2015
Hors ligne
A rejoint: 12/31/2012

I can't open Amazon due to non-free JavaScript, but looking for the
notebook at h-node returns me no results, this means that no one tested
it. If you don't want to run the risk of loosing money, please buy a
Respects Your Freedom hardware instead:

By buying a hardware that Respects Your Freedom, you are helping
organizations that care to make hardware that can run using only free
software to the extent possible/known by our movement/activism right

If you really can't buy one of these right now, then see this page and
look for a computer that rates at least B (Gold) in compatibility:


I am a member!

Hors ligne
A rejoint: 03/03/2016

I can visit amazon without javascript, but amazon is a terrible company:

So you might want to consider buying elsewhere. The websites ADFENO recommended are good places to start

If you don't want to spend more than $150, then getting a used Thinkpad can be an excellent choice. I bought a T400 for $125. Since the internal wifi does not work--which is very common--I bought an external wifi from Think Penguin for about $25. So total cost was < $160

If you want Libreboot installed, unless you are very handy, it will be about $200-$300 to install it. So you might be better off biting the bullet and getting something from the RYF page ADFENO gave you. Then you will get the computer with the Libreboot already installed.


I am a translator!

Hors ligne
A rejoint: 10/31/2014

> So you might want to consider buying elsewhere.

Ah, you were quicker than me. Don't buy from Amazon.

Trisk Spellian
Hors ligne
A rejoint: 03/20/2015

There's a guy on Open Bazaar that sells librebooted thinkpads and accepts Bitcoin as payment. He also responds to inquiries.



I am a member!

Hors ligne
A rejoint: 03/03/2016

I don't know why you were emailing them about Paypal root_vegetable, they have a large part of their site devoted to explaining these issues:
Here is the page, in case people have trouble getting to it for some reason:

PayPal? No way!

Minifree used to accept payments via PayPal, but since 7 December 2015, Minifree no longer accepts payments via PayPal. PayPal is evil.

Minifree accepts payments via wire transfer (SWIFT, BACS – direct bank to bank transfer), and has done so for some time now. This payment method has proven to be rather popular with our customers already; it is now the only option on the Minifree website.
Why are wire transfers better?

A wire transfer is when you (payee) give your bank account number (IBAN, SWIFT, etc) to the payer. They then give this information to their bank, and tell their bank to transfer the money to your bank account. This has been the standard way of sending money to foreign countries for decades.

Wire transfers usually have zero fees for the merchant, and usually low or zero fees for the purchaser (in the UK and other EU countries, it usually costs nothing to initiate a wire transfer). Not only that, but you’re not even taking any private financial details from the customer; this is far more secure by design, and it means that you don’t have to comply with PCI DSS standards, since you’re not taking card payments. Your bank also does not receive any private financial details about your customers.

There’s also another advantage: your website no longer needs to process payments. You simply give them your bank account number (IBAN, SWIFT, bank address, etc) and they can start the transfer at their bank without needing to use a computer; this means that there is no risk of proprietary JavaScript being needed at all. These days, most banks also provide their customers with a method to initiate wire transfers online, so it is virtually the same convenience-wise as debit/credit cards, while being much more secure.

It’s much more federated, since your customers will all have different bank accounts with different banks (in different countries); you’re removing an intermediary from the equation entirely. The way to accept wire transfers these days are also pretty much standardised in most of the world.

In practise, wire transfers are probably less susceptible to fraud (fraudulent buyers), because getting a bank account is much harder than getting a credit card in most countries, and often involves showing up to a meeting with your bank manager (your face will be on their cameras).

In some cases, a wire transfer can also be initiated somewhat anonymously. If you’re in the UK, you can walk into a branch, without a bank account, and pay cash at the counter, giving them Minifree’s sort code and account number, which they will then use to deposit that amount into Minifree’s account. You only need to specify the correct payment reference (usually the invoice number), and then the payment would be received and identified correctly.
What’s wrong with PayPal?

Here are just some of the things that PayPal does to projects/companies that use it:

Blocks payments, for no reason (PayPal did this to Minifree all the time. Customers often made several attempts before payments went through – we know this, we have the logs of failed order attempts, and memory of many telephone/email conversations with customers who had troubles ordering)
Freezes accounts (PayPal did this to Minifree, twice), regardless of whether all or most of your money is currently in the account.
Charges ridiculously high percentage fees to sellers, especially for income from foreign countries, despite the fact that PayPal provides poor quality service and is actually quite uncompetitive in general with other payment processors. (most credit/debit card processors are cheaper than PayPal, and don’t have nearly the same problems).
In addition to the high percentage value fees, PayPal’s foreign currency exchange rates are generally very low, so they rip you off twice. That, combined with blocking some payments, means that PayPal costs your business thousands per month or more, potentially.
PayPal is particularly hostile towards Free Software projects and companies related to Free Software development. (Minifree fits this bill, and the director of Minifree is also the lead developer of Libreboot, the free BIOS replacement that Minifree installs onto the computers that it sells)

Really? Just look at this well-known project and what they had to say:
They blocked Diaspora from receiving donations
More general information:
More general information:
They were also one of the payment processors that blocked WikiLeaks:
Many bittorrent-related projects that accept donations via PayPal are simply blocked (and threatened with legal action), even if what they’re doing is legal in their own country.

There are thousands of stories online. These are just a few examples pulled from a very large proverbial hat.

Initially, Minifree had decided to use PayPal because, as is often believed by small start ups, it seemed like an easy option to us, and it looked decent enough since so many other sites use it, even the big ones. It even offered an option for non-paypal-users to pay with a credit/debit card without creating a PayPal account. So we thought, it was acceptable. We were wrong.

Minifree apologises on behalf of all of its customers who felt compelled to use PayPal when ordering from Minifree (or Gluglug, Minifree’s previous incarnation) in the past, even if they hated PayPal. PayPal should never be used.
What about credit/debit cards?

This presents similar issues to PayPal. For low value sales, credit/debit cards certainly do make sense, but Minifree mainly focusses on higher-value (laptops, desktops, servers) and is not interested in anything else.

For processing card payments, the merchant has to be PCI DSS compliant; basically, they must comply with several security practises. Most merchants outsource to third party card processing facilities (which won’t be mentioned here), typically redirecting to a page on that providers website, for accepting payments. The problem with this is that they often serve proprietary JavaScript. However, the beauty here is that you’re not storing card details yourself, which means that your PCI compliance is quite easy and straightforward.

If you want to be absolutely sure that no proprietary JavaScript is used, then you must process (and store) card details yourself. You would still still typically use a third party (outsourcing company) for actually taking the payments, but you would be able to provide your own interface on your own website for taking details. This means that you yourself can control what JavaScript code is supplied to the user. There are several problems here:

You have to maintain the code, and make sure that everything works. You have to talk to the payment processor during checkout, for tokenization, validating cards and so on. They can change their API any time, without warning – this either means that you have to spend a lot of time maintaining the software on your website, or you have to pay a lot for them to do it (probably giving them access to your site, which introduces security issues).
The PCI DSS compliance becomes much more expensive and time consuming. Several checks have to be made every year, and there are many long questionaires to fill out.
This means that you have less time to focus on what actually matters; providing products and services to your customers.
You more or less have to self-host everything, and cannot outsource your hosting, because you have to make sure that everything is stored securely (how can you trust your webhosting provider to keep you secure? You have no way to verify their practises, and they won’t necessarily inform you of a breach or even be aware of one, and not only that, large hosting companies are large targets for intrusions for this exact reason)

Credit/debit card payment processors also typically take a very large portion of your income per sale; typically anywhere between 2-4 percent, usually on the higher end of this scale. It may seem small, but this percentage applies regardless of how much you charge for your products. For high value sales, this can become very expensive.

Even if you do meet PCI standards (which you have to) when taking card payments, think about it: you are being trusted to store peoples payment details in your company. Why should you need to do that? Is this not inherently insecure? What if a breach occurs?