Forums online, news to follow


Recommended Posts

Happy with the new Host ?

Think I saw Neobond say the old host where charging Neowin for extra bandwidth used.

No, I'm personally not. This is on a Cogent powered network. You will notice slower network transfer speeds and higher latency because it's a cheaper provider. The frigging connection between Dallas and Chicago was only 180Kb/s! What the hell is that?

On the upside, there's a bit better hardware available to us now and the codebase is up to the latest version, which has some things that should stop a lot of the freezing that was happening in MySQL before.

Also, I fixed the sync between the two webserver filesystems. I think we'll have to add another webserver soon and then start thinking about MySQL clustering (which gets interesting, to say the least...). These new servers are nice, but there's always room for Jello!

Actually, I'm curious to see how much slower the connection is for everyone. Can you ping these two addresses and post the results? 63.28.242.201 and 67.19.42.49

Should look like this:

Pinging 67.19.42.49 with 32 bytes of data:

Reply from 67.19.42.49: bytes=32 time=25ms TTL=242
Reply from 67.19.42.49: bytes=32 time=24ms TTL=242
Reply from 67.19.42.49: bytes=32 time=24ms TTL=242
Reply from 67.19.42.49: bytes=32 time=23ms TTL=242

Ping statistics for 67.19.42.49:
	Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
	Minimum = 23ms, Maximum = 25ms, Average = 24ms

inging 66.28.242.201 with 32 bytes of data:

eply from 66.28.242.201: bytes=32 time=56ms TTL=109
eply from 66.28.242.201: bytes=32 time=58ms TTL=109
eply from 66.28.242.201: bytes=32 time=57ms TTL=109
eply from 66.28.242.201: bytes=32 time=57ms TTL=109

ing statistics for 66.28.242.201:
   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
pproximate round trip times in milli-seconds:
   Minimum = 56ms, Maximum = 58ms, Average = 57ms

Hmm.. :/

ping 63.28.242.201

Pinging 63.28.242.201 with 32 bytes of data:

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Ping statistics for 63.28.242.201:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

ping 67.19.41.49

Pinging 67.19.41.49 with 32 bytes of data:

Reply from 67.19.41.49: bytes=32 time=166ms TTL=241

Reply from 67.19.41.49: bytes=32 time=171ms TTL=241

Reply from 67.19.41.49: bytes=32 time=281ms TTL=241

Reply from 67.19.41.49: bytes=32 time=187ms TTL=241

Ping statistics for 67.19.41.49:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 166ms, Maximum = 281ms, Average = 201ms

Pinging 66.28.242.201 with 32 bytes of data:

Reply from 66.28.242.201: bytes=32 time=326ms TTL=115

Reply from 66.28.242.201: bytes=32 time=324ms TTL=115

Reply from 66.28.242.201: bytes=32 time=323ms TTL=115

Reply from 66.28.242.201: bytes=32 time=327ms TTL=115

Ping statistics for 66.28.242.201:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss

Approximate round trip times in milli-seconds:

Minimum = 323ms, Maximum = 327ms, Average = 325ms

Reply from 67.19.42.49: bytes=32 time=343ms TTL=239

Reply from 67.19.42.49: bytes=32 time=393ms TTL=239

Reply from 67.19.42.49: bytes=32 time=342ms TTL=239

Reply from 67.19.42.49: bytes=32 time=362ms TTL=239

Ping statistics for 67.19.42.49:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 342ms, Maximum = 393ms, Average = 360ms

No, I'm personally not. This is on a Cogent powered network. You will notice slower network transfer speeds and higher latency because it's a cheaper provider. The frigging connection between Dallas and Chicago was only 180Kb/s! What the hell is that?

On the upside, there's a bit better hardware available to us now and the codebase is up to the latest version, which has some things that should stop a lot of the freezing that was happening in MySQL before.

Also, I fixed the sync between the two webserver filesystems. I think we'll have to add another webserver soon and then start thinking about MySQL clustering (which gets interesting, to say the least...). These new servers are nice, but there's always room for Jello!

Actually, I'm curious to see how much slower the connection is for everyone. Can you ping these two addresses and post the results? 63.28.242.201 and 67.19.42.49

Should look like this:

Pinging 67.19.42.49 with 32 bytes of data:

Reply from 67.19.42.49: bytes=32 time=25ms TTL=242
Reply from 67.19.42.49: bytes=32 time=24ms TTL=242
Reply from 67.19.42.49: bytes=32 time=24ms TTL=242
Reply from 67.19.42.49: bytes=32 time=23ms TTL=242

Ping statistics for 67.19.42.49:
	Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
	Minimum = 23ms, Maximum = 25ms, Average = 24ms

inging 66.28.242.201 with 32 bytes of data:

eply from 66.28.242.201: bytes=32 time=56ms TTL=109
eply from 66.28.242.201: bytes=32 time=58ms TTL=109
eply from 66.28.242.201: bytes=32 time=57ms TTL=109
eply from 66.28.242.201: bytes=32 time=57ms TTL=109

ing statistics for 66.28.242.201:
   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
pproximate round trip times in milli-seconds:
   Minimum = 56ms, Maximum = 58ms, Average = 57ms

Did you mean 66.28.242.201 and not 63.28.242.201, because I get Request Timed Out on 63.28.242.201, and I noticed you used 66.28.242.201 in your ping results. :p

Anyway, here are my results.

Pinging 66.28.242.201 with 32 bytes of data:

Reply from 66.28.242.201: bytes=32 time=57ms TTL=238
Reply from 66.28.242.201: bytes=32 time=97ms TTL=238
Reply from 66.28.242.201: bytes=32 time=156ms TTL=238
Reply from 66.28.242.201: bytes=32 time=45ms TTL=238

Ping statistics for 66.28.242.201:
   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
   Minimum = 45ms, Maximum = 156ms, Average = 88ms

Pinging 67.19.42.49 with 32 bytes of data:

Reply from 67.19.42.49: bytes=32 time=46ms TTL=238
Reply from 67.19.42.49: bytes=32 time=135ms TTL=238
Reply from 67.19.42.49: bytes=32 time=46ms TTL=238
Reply from 67.19.42.49: bytes=32 time=46ms TTL=238

Ping statistics for 67.19.42.49:
   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
   Minimum = 46ms, Maximum = 135ms, Average = 68ms

Heh. I woke up to find Neowin still on my computer screen. (it was a thread I left open. lol. I closed it and re-open it to get fresh tthreads or news but got told the servers were down. lol.

btw I am now known as ozgeek, not mr.roberts. (ozgeek stands for Australian geek).

and timdorr how do I ping for you? is it ping via cmd?

Hmmm... I can go to neowin.net/forum, yet all the links inside point to neowin5.net/forum/whatever... Kind of strange... Is this still a result of the DNS servers or what?

Hey I just noticed that now I know how many stars I have to go to reach the end :D Just 3 left...

Mine ...

Pinging 67.19.42.49 with 32 bytes of data:

Reply from 67.19.42.49: bytes=32 time=179ms TTL=239

Reply from 67.19.42.49: bytes=32 time=180ms TTL=239

Reply from 67.19.42.49: bytes=32 time=189ms TTL=239

Reply from 67.19.42.49: bytes=32 time=179ms TTL=239

Ping statistics for 67.19.42.49:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 179ms, Maximum = 189ms, Average = 181ms

Pinging 66.28.242.201 with 32 bytes of data:

Reply from 66.28.242.201: bytes=32 time=167ms TTL=112

Reply from 66.28.242.201: bytes=32 time=167ms TTL=112

Reply from 66.28.242.201: bytes=32 time=165ms TTL=112

Reply from 66.28.242.201: bytes=32 time=167ms TTL=112

Ping statistics for 66.28.242.201:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 165ms, Maximum = 167ms, Average = 166ms

Reply from 67.19.42.49: bytes=32 time=131ms TTL=236
Reply from 67.19.42.49: bytes=32 time=123ms TTL=236
Reply from 67.19.42.49: bytes=32 time=123ms TTL=237
Reply from 67.19.42.49: bytes=32 time=126ms TTL=237

Ping statistics for 67.19.42.49:
	Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
	Minimum = 123ms, Maximum = 131ms, Average = 125ms


Pinging 66.28.242.201 with 32 bytes of data:

Reply from 66.28.242.201: bytes=32 time=120ms TTL=113
Reply from 66.28.242.201: bytes=32 time=120ms TTL=113
Reply from 66.28.242.201: bytes=32 time=121ms TTL=113
Reply from 66.28.242.201: bytes=32 time=122ms TTL=113

Ping statistics for 66.28.242.201:
	Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
	Minimum = 120ms, Maximum = 122ms, Average = 120ms

Last login: Tue Nov 29 20:55:27 on ttyp1

Welcome to Darwin!

nicholas-pachecos-mac-mini:~ Nicholas$ ping 67.19.42.49

PING 67.19.42.49 (67.19.42.49): 56 data bytes

64 bytes from 67.19.42.49: icmp_seq=0 ttl=241 time=49.703 ms

64 bytes from 67.19.42.49: icmp_seq=1 ttl=241 time=59.904 ms

64 bytes from 67.19.42.49: icmp_seq=2 ttl=241 time=84.557 ms

64 bytes from 67.19.42.49: icmp_seq=3 ttl=241 time=47.258 ms

64 bytes from 67.19.42.49: icmp_seq=4 ttl=241 time=48.742 ms

64 bytes from 67.19.42.49: icmp_seq=5 ttl=241 time=52.378 ms

^C

--- 67.19.42.49 ping statistics ---

6 packets transmitted, 6 packets received, 0% packet loss

round-trip min/avg/max/stddev = 47.258/57.090/84.557/12.945 ms

nicholas-pachecos-mac-mini:~ Nicholas$

Pinging 67.19.42.49 with 32 bytes of data:

Reply from 67.19.42.49: bytes=32 time=102ms TTL=243
Reply from 67.19.42.49: bytes=32 time=100ms TTL=243
Reply from 67.19.42.49: bytes=32 time=96ms TTL=243
Reply from 67.19.42.49: bytes=32 time=100ms TTL=243

Ping statistics for 67.19.42.49:
	Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
	Minimum = 96ms, Maximum = 102ms, Average = 99ms 

Pinging 66.28.242.201 with 32 bytes of data:

Reply from 66.28.242.201: bytes=32 time=115ms TTL=105
Reply from 66.28.242.201: bytes=32 time=130ms TTL=105
Reply from 66.28.242.201: bytes=32 time=114ms TTL=105
Reply from 66.28.242.201: bytes=32 time=114ms TTL=105

Ping statistics for 66.28.242.201:
	Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
	Minimum = 114ms, Maximum = 130ms, Average = 118ms

No, I'm personally not. This is on a Cogent powered network. You will notice slower network transfer speeds and higher latency because it's a cheaper provider. The frigging connection between Dallas and Chicago was only 180Kb/s! What the hell is that?

On the upside, there's a bit better hardware available to us now and the codebase is up to the latest version, which has some things that should stop a lot of the freezing that was happening in MySQL before.

Also, I fixed the sync between the two webserver filesystems. I think we'll have to add another webserver soon and then start thinking about MySQL clustering (which gets interesting, to say the least...). These new servers are nice, but there's always room for Jello!

Actually, I'm curious to see how much slower the connection is for everyone. Can you ping these two addresses and post the results? 63.28.242.201 and 67.19.42.49

Timdorr, Other than ping time the thing interests me is the number of hops inside the network look at the number of hops once I get inside the cogentco network.

traceroute to neowin.net (66.28.242.203), 30 hops max, 40 byte packets
 1  vlan250.lon-service6.Melbourne.telstra.net (203.50.2.177)  0.335 ms  0.202 ms  0.258 ms
 2  10GigabitEthernet9-0.win-core1.Melbourne.telstra.net (203.50.79.129)  0.357 ms  0.389 ms  0.259 ms
 3  Pos-Channel2.ken-core4.Sydney.telstra.net (203.50.6.21)  12.936 ms  12.972 ms  12.984 ms
 4  10GigabitEthernet3-0.pad-core4.Sydney.telstra.net (203.50.6.86)  32.545 ms  12.983 ms  12.982 ms
 5  10GigabitEthernet2-2.syd-core02.Sydney.net.reach.com (203.50.13.42)  13.234 ms  13.208 ms  13.17 ms
 6  i-0-0.wil-core02.net.reach.com (202.84.144.101)  161.363 ms  161.335 ms  161.353 ms
 7  unknown.net.reach.com (202.84.251.166)  160.962 ms  160.91 ms  160.872 ms
 8  unassign.net.reach.com (134.159.63.66)  160.952 ms  160.934 ms  160.844 ms
 9  p6-0.core01.lax01.atlas.cogentco.com (154.54.2.209)  162.04 ms  162.152 ms  162.201 ms
10  p5-0.core01.san01.atlas.cogentco.com (66.28.4.78)  163.916 ms  163.649 ms  163.72 ms
11  p6-0.core01.iah01.atlas.cogentco.com (66.28.4.5)  195.383 ms  195.381 ms  195.81 ms
12  p13-0.core01.mci01.atlas.cogentco.com (66.28.4.106)  223.775 ms  223.66 ms  223.736 ms
13  p5-0.core02.ord01.atlas.cogentco.com (66.28.4.34)  234.876 ms  235.536 ms  234.794 ms
14  p12-0.core03.ord01.atlas.cogentco.com (154.54.3.154)  234.369 ms  234.337 ms  234.413 ms
15  p2-0.core01.ord04.atlas.cogentco.com (154.54.3.42)  235.05 ms  234.902 ms  234.985 ms
16  g3-1.hc01.ord04.atlas.cogentco.com (204.6.150.30)  234.651 ms  234.532 ms  234.636 ms
17  StardockCorporation.demarc.cogentco.com (38.112.15.250)  234.951 ms  234.965 ms  235.292 ms
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Here's my ping times:

Reply from 67.19.42.49: bytes=32 time=42ms TTL=244

Reply from 67.19.42.49: bytes=32 time=42ms TTL=244

Reply from 67.19.42.49: bytes=32 time=42ms TTL=244

Reply from 67.19.42.49: bytes=32 time=42ms TTL=244

Ping statistics for 67.19.42.49:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 42ms, Maximum = 42ms, Average = 42ms

and

Pinging 66.28.242.201 with 32 bytes of data:

Reply from 66.28.242.201: bytes=32 time=69ms TTL=114

Reply from 66.28.242.201: bytes=32 time=158ms TTL=114

Reply from 66.28.242.201: bytes=32 time=144ms TTL=114

Reply from 66.28.242.201: bytes=32 time=70ms TTL=114

Ping statistics for 66.28.242.201:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 69ms, Maximum = 158ms, Average = 110ms

That second server's not as fast to respond...

Pinging 67.19.42.49 with 32 bytes of data:

Reply from 67.19.42.49: bytes=32 time=115ms TTL=233

Reply from 67.19.42.49: bytes=32 time=129ms TTL=233

Reply from 67.19.42.49: bytes=32 time=127ms TTL=233

Reply from 67.19.42.49: bytes=32 time=116ms TTL=232

Ping statistics for 67.19.42.49:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 115ms, Maximum = 129ms, Average = 121ms

Pinging 66.28.242.201 with 32 bytes of data:

Reply from 66.28.242.201: bytes=32 time=123ms TTL=107

Reply from 66.28.242.201: bytes=32 time=123ms TTL=107

Reply from 66.28.242.201: bytes=32 time=124ms TTL=107

Reply from 66.28.242.201: bytes=32 time=123ms TTL=107

Ping statistics for 66.28.242.201:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 123ms, Maximum = 124ms, Average = 123ms

Pretty adverage ping times for me.

Keep up all the good work <3

Whoops, yep, I meant 66.28.242.201. Sorry about that. Just curious, though. No biggie :)

and for that IP still a lot of hops insde that network

traceroute to 66.28.242.201 (66.28.242.201), 30 hops max, 40 byte packets
 1  vlan250.lon-service6.Melbourne.telstra.net (203.50.2.177)  0.339 ms  0.358 ms  0.24 ms
 2  10GigabitEthernet9-0.win-core1.Melbourne.telstra.net (203.50.79.129)  0.341 ms  0.281 ms  0.389 ms
 3  Pos-Channel2.ken-core4.Sydney.telstra.net (203.50.6.21)  13.067 ms  12.866 ms  12.965 ms
 4  10GigabitEthernet3-0.pad-core4.Sydney.telstra.net (203.50.6.86)  12.923 ms  13.025 ms  12.967 ms
 5  10GigabitEthernet2-2.syd-core02.Sydney.net.reach.com (203.50.13.42)  13.213 ms  13.205 ms  13.21 ms
 6  i-0-0.wil-core02.net.reach.com (202.84.144.101)  161.414 ms  161.362 ms  161.34 ms
 7  unknown.net.reach.com (202.84.251.166)  246.252 ms  160.911 ms  160.839 ms
 8  unassign.net.reach.com (134.159.63.66)  160.858 ms  160.93 ms  160.977 ms
 9  p15-0.core01.lax01.atlas.cogentco.com (154.54.2.213)  161.429 ms  161.372 ms  161.707 ms
10  p5-0.core01.san01.atlas.cogentco.com (66.28.4.78)  163.94 ms  163.584 ms  163.764 ms
11  p6-0.core01.iah01.atlas.cogentco.com (66.28.4.5)  195.505 ms  196.641 ms  195.494 ms
12  p13-0.core01.mci01.atlas.cogentco.com (66.28.4.106)  223.754 ms  223.725 ms  223.642 ms
13  p5-0.core02.ord01.atlas.cogentco.com (66.28.4.34)  235.219 ms  234.752 ms  234.889 ms
14  p12-0.core03.ord01.atlas.cogentco.com (154.54.3.154)  234.494 ms  234.479 ms  234.522 ms
15  p2-0.core01.ord04.atlas.cogentco.com (154.54.3.42)  235.082 ms  235.106 ms  234.924 ms
16  g3-2.hc01.ord04.atlas.cogentco.com (204.6.150.34)  235.012 ms  235.066 ms  235.036 ms
17  StardockCorporation.demarc.cogentco.com (38.112.15.250)  234.916 ms  234.771 ms  234.756 ms
18  66.28.242.201 (66.28.242.201)  234.784 ms  236.982 ms  234.748 ms

From the UK...

Pinging 66.28.242.201 with 32 bytes of data:

Reply from 66.28.242.201: bytes=32 time=114ms TTL=114
Reply from 66.28.242.201: bytes=32 time=115ms TTL=114
Reply from 66.28.242.201: bytes=32 time=116ms TTL=114
Reply from 66.28.242.201: bytes=32 time=115ms TTL=114

Ping statistics for 66.28.242.201:
	Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
	Minimum = 114ms, Maximum = 116ms, Average = 115ms

Pinging 67.19.42.49 with 32 bytes of data:

Reply from 67.19.42.49: bytes=32 time=164ms TTL=245
Reply from 67.19.42.49: bytes=32 time=163ms TTL=245
Reply from 67.19.42.49: bytes=32 time=161ms TTL=245
Reply from 67.19.42.49: bytes=32 time=162ms TTL=245

Ping statistics for 67.19.42.49:
	Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
	Minimum = 161ms, Maximum = 164ms, Average = 162ms

Edit: ooooo, quick edit is niiiiice

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • No, size is not the only selling point. I did not even remotely say that. Your claim was that "building your own will be faster and cheaper". This is false. You cannot build something close to that form factor with off-the-shelf parts. You can build a Mini-ITX PC and pay more, or something larger and pay less. But these are different market segments. It's apples and oranges.
    • There is a default resolution setting in Settings > Display that can be changed with a click. You can also change the settings on a per-game basis. No CLI needed. Also, Steam has countless games that are not "[perpetual] alpha/beta games", so no need for the straw man. Plus you can use other stores as well. And console games (e.g. PS5) cost a fortune, which itself more than negates the price subsidy on the system, unless you plan on exclusively playing 1 or 2 games. It's true that you shouldn't buy a system that doesn't support the game(s) you want to play, but I think that's kinda obvious, and applies to every console as well as PC. I don't game in the living room and have no need of a Steam Machine, but there is a clear market segment that would find it useful.
    • RSS Guard 5.2.0 by Razvan Serea RSS Guard is a simple (yet powerful) feed reader. It is able to fetch the most known feed formats, including RSS/RDF and ATOM. It's free, it's open-source. RSS Guard currently supports Czech, Dutch, English, French, German, Italian. RSS Guard will never depend on other services - this includes online news aggregators like Feedly, The Old Reader and others. RSS Guard is developed on top of the Qt library and it supports these operating systems: Windows GNU/Linux OS/2 (eComStation) Mac OS X xBSD (possibly) Android (possibly) other platforms supported by Qt The core features of RSS Guard are: support for online feed synchronization via plugins, Tiny Tiny RSS (from RSS Guard 3.0.0). multiplatform, support for all feed formats, simplicity, import/export of feeds to/from OPML 2.0, downloader with own tab and support for up to 6 parallel downloads, message filter with regular expressions, feed metadata fetching including icons, simple Adblock functionality, customized popup notifications, Google-based auto-completion for internal web browser location bar, ability to cleanup internal message database with various options, enhanced feed auto-updating with separate time intervals, multiple data backend support, SQLite (in-memory DBs too), MySQL. is able to specify target database by its name (MySQL backend), “portable” mode support with clever auto-detection, feed categorization, drap-n-drop for feed list, automatic checking for updates, ability to discover existing feeds on websites, full support of podcasts (both RSS & ATOM), ability to backup/restore database or settings, fully-featured recycle bin, printing of messages and any web pages, can be fully controlled via keyboard, feed authentication (Digest-MD5, BASIC, NTLM-2), handles tons of messages & feeds, sweet look & feel, fully adjustable toolbars (changeable buttons and style), ability to check for updates on all platforms + self-updating on Windows, hideable main menu, toolbars and list headers, KFeanza-based default icon theme + ability to create your own icon themes, fully skinnable user interface + ability to create your own skins, “newspaper” view, plenty of skins, support for "feed://" URI scheme, ability to hide list of feeds/categories, open-source development model based on GNU GPL license, version 3, tabbed interface, integrated web browser with adjustable behavior + external browser support, internal web browser mouse gestures support, desktop integration via tray icon, localizations to some languages, Qt library is the only dependency, open-source development model and friendly author waiting for your feedback, no ads, no hidden costs. RSS Guard 5.2.0 changelog: Added: Feed auto-fetch can now also be delayed while Feral GameMode is active on Linux and startup auto-fetch is skipped when GameMode is already active. (#2265) WebEngine builds can now use RSS Guard generated proxy auto-config (PAC) rules so article/web browsing follows per-account and per-feed proxy settings more closely. (#2273) Generated PAC rules now also cover related subdomains and use Public Suffix List data, so feeds such as feeds.bbc.co.uk can also proxy resources from images.bbc.co.uk. (#2273) Standard feeds can now define extra proxy domains, useful when article images, stylesheets or other page resources are loaded from a CDN or another domain that should use the same feed proxy. (#2273) RSS Guard now asks for proxy credentials when a WebEngine page needs proxy authentication and can fill credentials from the current feed proxy when available. (#2273) Network settings again include an option to ignore all cookies, which clears stored cookies and prevents new cookies from being accepted. Standard RSS/ATOM feeds can now individually ignore cookies while downloading feed data. Stored cookies can now be deleted from the Tools menu. Custom skin colors can now override the feed list article count color separately from feed titles, including a separate highlighted color. (#2275) Settings dialog can now search across available settings and highlight matching controls. (#1754) Standard RSS/ATOM feeds can now optionally be reported as broken when they are valid but contain no articles. (#2039) Standard RSS/ATOM feeds can now override the application-wide feed connection timeout per feed. (#1023) Tray icon can now use a custom background color and unread-count text color, with an option to reuse the generated icon as the application icon. (#1973) Support for more benevolent parsing of Gemlog entries (#2295). Article list can now show when an article was received by RSS Guard. (#947) Feed deep discovery now actually scrapes all links found in the website and checks if they are feeds or not. This greatly enhances usability of the deep discovery mode and discovers many more feeds than before. (#2306) Search boxes now show a small dot when the feed or article list is hiding some items because of active filtering. (#873) Articles now have a shortcut-assignable action to open the homepage of the feed they belong to. (#2060) Fixed: Parallel feed updates no longer crash when multiple update results are processed at the same time. (64cf521) Links in WebEngine articles opened from feeds such as Kill the Newsletter now open correctly instead of being swallowed by the embedded page. (#2272) Relative article URLs resolution was kinda broken. (#2282) Clicking article URL did not work when the URL had "fragment" set. (#2293) The default proxy setting now uses Qt/system default proxy behavior instead of forcing no proxy. (e0263ad) WebEngine article loading now keeps the current feed context, so feed-specific proxy credentials remain available while the article page loads. (fdd0f00) Download: RSS Guard 5.2.0 (64-bit) | Portable | ~ 130.0 MB (Open Source) Link: RSS Guard Home Page | Other Operating Systems | Screenshot Get alerted to all of our Software updates on Twitter at @NeowinSoftware
    • This is gonna separate the creeps from the rest of the crowd.
  • Recent Achievements

    • Rookie
      DaviKar went up a rank
      Rookie
    • Dedicated
      HidekoYamamoto94 earned a badge
      Dedicated
    • One Month Later
      timbobit earned a badge
      One Month Later
    • One Month Later
      nates earned a badge
      One Month Later
    • Week One Done
      Almohandis earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      462
    2. 2
      +Edouard
      161
    3. 3
      PsYcHoKiLLa
      110
    4. 4
      Michael Scrip
      83
    5. 5
      Steven P.
      69
  • Tell a friend

    Love Neowin? Tell a friend!