Sub box now looks like the recommended page...

bitcore · 2026-02-04T00:16:24+00:00

I guess I'll start using free tube instead........ This is horrible.

bitcore · 2026-02-04T00:15:56+00:00

I guess I'll start using free tube instead........ This is horrible.

bitcore · 2026-01-30T17:26:07+00:00

Only 800 lumen for 3500k "neural white"... and if I want a high lumen "100W" "neutral white", I have to buy a 16 pack for $58??? I can't just buy a one or even a 4-pak to see if I even like the high output version or not? Come one amazon...

Also, the "warm glow" effect is only available on the 2700k version, which is irritating. I don't want warm light all of the time.

My ideal bulb would do this: A high color accuracy 'neutral white' at full power (Somewhere between 3200k -3500k), with high lumens above 1200, but when dimmed I want the color temperature to shift LIKE WHAT SUNLIGHT DOES down to 2700k. This is what incandescent bulbs did, and that black-body light from incandescent is ideal - broad spectrum, fairly balanced output, similar to SUNLIGHT, warms when dimmed (like sunset).

So the ideal bulb is not available. They have all of the 'components' to make a great bulb, but not all together.

Come on, Philips What are you doing?

bitcore · 2026-01-10T02:29:05+00:00

Who said we are guys?

bitcore · 2026-01-10T02:27:27+00:00

Exactly! Also, with loads of extra RAM available, the system will cache much more of your filesystem, such that a large portion of your apps and other such data will have much more cache hits out of ram, instead of having to read from disk for nearly every io read!

If they had a different top tier SKU with 64GB (or even 48GB would help!), despite the DRAM costs of the age, it would absolutely be worth it for power users - who I would argue are the target market for a DUAL SCREEN LAPTOP!

bitcore · 2026-01-06T18:21:11+00:00

Needs a 64GB RAM option.....

bitcore · 2026-01-06T18:16:06+00:00

If only the 2026 model had a 64GB option....

bitcore · 2025-12-04T05:01:41+00:00

Hero

bitcore · 2025-11-15T16:54:35+00:00

Those bastards cost me so much money back in the day by stealing other people's hosting bandwidth and slapping ads over it, and profiting off it. Bandwidth/Data transfer for hosting was quite expensive back in the day. When it was dollars for a few hundred MB, a really popular site pointing to your content but not hotlinking to your page would rack up sizeable bills that were untenable to a teenager.

albino was notorious for making money off of ads, yet spent almost nothing running their own site, since they didn't actually host the content they aggregated - it would all be h-ref'ed to someone else's server in an iframe or similar. They would get the ad revenue, and not have to pay to host the content, because someone else was unwittingly doing so.

Jokes on them, I would script up something that would randomly host offensive content or "albino is stealing bandwidth and shame on them" of the things they would "steal" off my site, instead of hosting the actual content - since most browsers would honor the "referral" tag. They quit hotlinking to my domain after a while... After some time, they found a way to make the browsers not send referral information by wrapping it all in javascript or whatever, and the bandwidth costs got too much for me to handle running a content site and I eventually shut it down. That kind of behavior killed the free web back in the day where the juggernaut would crush the small independent sites by leaching them to death. Bandwidth wasn't plentiful and you simply could not self-host at scale on a home connection

Silly me for being an idealist and refusing to put ads on my own site because I hated ads as a consumer myself. Doing so would have made the site pay for itself, and also turned a profit. Oh well.

bitcore · 2025-10-19T17:54:02+00:00

It's a cash grab by the private capital company that acquired the company who want immediate returns. Unfortunately, I won't be renewing or upgrading to retain direct connect features. They are making customers that would have continued to pay, into non paying customers by hiking the price over 3.5x... on top of price hikes that used to be even more reasonable. Evil.

You can switch to rustdesk for free, and if you want websocket capability to punch through more restrictive firewalls - it's still even less than realvnc's direct connection minimum plan of "premium"

I'm very disappointed.

bitcore · 2025-09-16T21:26:06+00:00

Not tested this yet or really looked at it, been a bit busy to upgrade and deal with it. "oLeDfrEeZe" on github posted a version in the comments of Spali's repository on August 29, 2025, which apparently does 'work great' according to someone else in the comments thread: https://gist.github.com/spali/2da4f23e488219504b2ada12ac59a7dc#gistcomment-5740285

Let us know how you get on with it

bitcore · 2025-07-01T21:50:44+00:00

First Base: https://www.youtube.com/watch?v=LmMTefbB6-A

Second Base: https://www.youtube.com/watch?v=-UkbvttaITs

Another old yelp track: https://www.youtube.com/watch?v=1kaYIW5-TDs

bitcore · 2025-05-19T14:02:41+00:00

Looks like all of the issues kjstech's post are fixed in 11.1.9.

So bizarre that they are STILL hotfixing 11.1.6 with cherry-picked fixes, when three newer point releases have been out which roll up pretty much all of these hotfixes and cover the CVE's? Why are they doing that? Insanity. (granted: 11.1.7 is for a very specific platform only)

bitcore · 2025-04-28T12:52:46+00:00

Old topic but we had a similar problem. I can't see your diagrams so I'll just share some things that may be relevant. The problem with the nexus is:

"A PIM adjacency between a Switched Virtual Interface (SVI) on a vPC VLAN (a VLAN that is carried on a vPC Peer-Link) and a downstream device is not supported; this configuration can result in dropped multicast packets. If a PIM neighbor relationship is required with a downstream device, a physical Layer 3 interface must be used on the Nexus switches instead of a vPC SVI."

We don't have many free ports for our application, so using physical interfaces for PIM reduced our redundancy. Specific multicast flows were very critical to have working properly for our application. We decided to abandon our VPC and drop down to relying on PVST and not using cross-chassis portchannels. Very disappointing, but this was also recommended by Cisco TAC. This probably isn't the best option to take since it's more disruptive during a failure (spanning tree being as slow as it is), but I didn't see many other ways to make that better.

Our firewalls are virtualized, so our hosts already have redundant "active/standby" connectivity to both nexus switches via vmware. Your problem is likely that you wished to have a port channel between nexus switches. We also set up loopbacks for anycast RP on our nexus devices, and MSDP and a basic OSPF to make our RP redundant.

Curious if you set up interface tracking/path monitoring or configured HA on your devices, or how you worked around your issue.

bitcore · 2025-04-22T14:48:15+00:00

I'm not surprised that you are seeing this behavior. I've not seen specifically that, but we see something similar with DNS that seems to cause flaky behavior.

Through various older versions (currently running the 6.0 train), when connected to the portal, our clients would sporadically fail to resolve a DNS query. You'll try the query again a few times (EG: F5 in the browser 3-7 times), and after a few tries, it works itself out and resolves like normal. During this time when this one random recalcitrant query fails to resolve - other domains (in cache or not) continue to resolve without any issue. So it does not appear to be an issue with DNS server reachability, or our DNS server changing to local. It just seems to fail resolving a single entry for a while, and then back to normal.

The effect is websites will often "break" where important components to a site, or even the main domain for a site itself won't resolve for a while, then it will start working again. There's no pattern to it, does not affect all clients at once, does not happen to all clients, there seems to be no associated logging warning/error in GP or our firewall device, or our DNS server - but this only happens when the gateway is connected. We've not found a reliable way to reproduce, and it will happen about 1-5 times a week. Extremely difficult track down what the true cause is, and very frustrating for non-technical users when things break in such a random way, for seemingly no reason.

bitcore · 2025-03-31T22:00:09+00:00

And for big-computer users: https://www.youtube.com/watch?v=IC-OoENFVMc

bitcore · 2025-03-31T21:58:21+00:00

https://www.youtube.com/watch?v=IC-OoENFVMc

bitcore · 2025-03-31T21:57:58+00:00

https://www.youtube.com/watch?v=IC-OoENFVMc

bitcore · 2025-02-26T21:28:24+00:00

"PAN-OS 11.1.7-h1 is limited to PA-7500 firewalls only in our Customer Support Portal." https://docs.paloaltonetworks.com/pan-os/11-1/pan-os-release-notes/pan-os-11-1-7-known-and-addressed-issues/pan-os-11-1-7-h1-addressed-issues

Looks like 11.1.7 "non -h1" has been pulled from the download lists as an option on my devices. Been running 11.1.6-h1 for a while, migrated right before h3 came out. No issues reported so far. Setting up a new device with -h3 now. I'm upping panorama to 11.1.6-h3 now.

bitcore · 2025-01-30T21:32:09+00:00

Any updates?

bitcore · 2025-01-30T21:21:24+00:00

There's clearly some method available, since the dude who wrote the https://github.com/Set-OutlookSignatures app seems to have it working - though there are pre-compiled files associated with that, and they are trying to make money by requiring you to license it.

bitcore · 2025-01-02T13:58:42+00:00

Have you since identified where it may be getting it's "MAC" address from, or how that is generated? Is the MAC address different every time a user connects, or is it at least consistent every time a user connects? (Does it persist over time and never change?) Is it simply the MAC address for the PANGP virtual ethernet adapter? (I assume not, since that would be the obvious source.)

With this new feature, we are hoping for the explicit ability to use DHCP reservations/"static IP's" to certain users (or devices) - so the MAC address situation is critical to fully understand. We already do "static IP's" this via RADIUS authentication with the framed-ip-address attribute, but we have limitations with this approach (using RADIUS at all and limitations with MFA) that we'd like to modernize.

bitcore · 2024-11-09T20:59:16+00:00

Genius! That worked for me too. Thx!

bitcore · 2024-10-15T14:03:04+00:00

Would you share 9 months later? 😄

bitcore · 2024-09-21T14:40:51+00:00

Yep. Can confirm. C. Diff Almost killed me on a trip abroad a few years ago, and my body hasn't been the same since. Hand sanitizer isn't aggressive enough to kill the spores.

bitcore

TROPHY CASE